API's that Suck

March 12, 2011

Design Driven Development

Filed under: Uncategorized — Grauenwolf @ 5:56 pm

Step 1: Requirements

Read the requirements. All of them. Breath them in and get a feel for what the customer really wants. And how that changed since you last read them all.

Once you feel the Tao of the project, grab a block of related requirements. How big of a block? Whatever feels right. We call this a “feature”.

Step 2: Design the Features

Start by writing the use cases, the step by step explanation of how the feature is going to actually work from the user’s perspective. Then start adding any database schema, class diagrams, test cases, flowcharts, and anything else you need to understand the feature. The key word here is “you”. No one else needs to see the design documents. Well, unless you happen to be using them a prop to show why they are high.

Step 3: Bitch about the Requirements

Invariably the requirements are going to have holes, areas that are unclear, underspecified, or written by someone who is clearly high. The only purpose of the design process is to find those holes and get them fixed. Once you fill your written design with highlighted question marks, crack open a beer and relax. It is going to take product management ages to figure out what the hell they really wanted you to build.

Step 4: Review the Design

Get a good night’s sleep. Or party till you drop. It doesn’t really matter, just so long as you let the design age a bit.

Now take a look at it. Does it still make sense? Or was it clearly written by a crack head and need to be redone?

Step 5: Hacking

Now you know exactly what you want its time to grab some energy drinks and start writing the code. If you are using automated testing now is the time to slap them together. Heck, you can even go full TDD at this point. I prefer ADD, but that’s just me. Just don’t forget to update the design documents with whatever edge cases or significant redesigns you happen across.

Step 6: Testing

Remember all those use cases and test cases you wrote back in step 2. Of course not. Go look at them again, I’ll wait…

Now really test your code. Automated what-you-ma-call-its don’t count at this point. Actually go through the requirements and design documents and verify everything matches what you expected.

Step 7: Documentation

Find your tests cases can give them to the QA department. Then throw everything else away. You know damn well you aren’t going to keep it updated, so don’t even bother pretending you will do otherwise.


Blog at WordPress.com.