Design By Example

Yesterday I talked about Design by Counter-Example. What about the opposite? You know what you want to do (the user story), but you don’t know how to do it, or what the API and internals should look like. How might that work?

You’d start with a real world problem. A user story that describes a way to make the user’s world better. Better by adding some value. It might be by eliminating manual work, reducing the number of steps, or some whole new way of approaching the problem that solves a user’s problem.

You’d work with the user, discussing options and priorities. You might go to the whiteboard and draw boxes and arrows. Maybe use Visio or Google Draw to make a shareable version. Whatever it takes to understand the domain and how you’re adding value.

Then you think about it a little. And come up with some pseudo-code that shows how you envision adding value to the user. It doesn’t work of course, because none of it really exists, but you get some more feedback from the user and can feel pretty confident that it really will add value.

Finally (really, it’s only been hours, maybe a day or so), you go to your favorite IDE and turn that pseudo-code into real code, but still making calls to non-existent functions and APIs. So you start to fill in those gaps.

You start simple. At first you just blindly return some happy path answers. Things check out, so you continue. Then maybe you add some input and state validation. You check with your user and make sure you’re still adding value. You’ve learned a little, so maybe you tweak the example code a little.

You keep adding depth and detail until all of the examples work and you release the new benefit to the user and they’re happy.

That’s test driven development design by example.