Get a clue! or .. write a requirement

Guys and gals, we’ve all done it. Written code without requirements. Me too. Guilty.

However what is your preference? Are you the developer that needs a mountain of documentation that details your every line of code?

Are you the developer that thrives on having some creativity by just having a loose outline of what is expected and then you design from there?  Are you the in-between guy/gal?

For my part, I’m the developer that likes a good bit of … let’s call them .. “agreed upon goals” shall we?   For me working from verbal requirements PLUS the added fun of a hard-deadline is probably the most stifling thing there can be.  It is just like running a marathon, where you don’t know how far you have to go or which road to take the next day; you just know when you have to cross the finish line.

Fun huh?  If we were in Tron right now, I’d ask you to whack me with your Identity Disc and Derez me.

The perfect balance for me in regards to requirements is a bulleted list.  I often do this for myself in both personal as well as professional projects.  Cause I’m all cool-nerd like that right?

But seriously, creating a simple list gets the ideas out of my head, captures them so they don’t fly away, and lets me design/code.  If you find yourself in a place that won’t slow down long enough to think about and capture even the most simple list, methinks it could identify a problem which needs overcoming.

The good news is that you don’t have to quit and find another job sparky.  There are sneaky ways to create your own documentation and even get management to sign off on it.

EMAIL.

Obvious huh?  This works, though.

Simply write a clear, concise email stating things as you understand them needing to be done (requirements) and get an answer (signoff).  Then keep the email for extra-vacation-blackmail later .. I kid 🙂

Most managers/clients I’ve worked for are delighted with a developer that shows this kind of initiative (not with blackmail, only the email part).  So it’s a win-win.  You get what you need … an avoidance of a trip to the looney bin from stressing out over your project .. and your manager/client gets what they want too .. working software.

See?  Easy-peezy, lemon squeezy.

Now of course, if there is NO time for requirements and nobody will/can/or wants to slow down long enough to design something .. and they’d prefer to just throw code at until something works .. welllllll, that’s another topic for another day kids!