John Wood

Test Driven Development or Business Driven Development?

When my 1 year-old wants something she enthusiastically points and babbles and then waits for me to reciprocate. Is it water she wants? The ball on the table? The stuffed cow? It's difficult to tell. I end up just giving her everything that somewhat intersects with the path of her pointing (and usually moving) finger until she squeals with joy and hugs the object like a long-lost friend.

While her pointing is a vague form of requirement specification, the lit up face, squeal and excited reaction constitutes the test that tells me whether I hit the mark.

So what does this have to do with Test Driven Development? Effectively, with only a little hint, I'm determining the requirements based on the reaction to the tests. The tests are driving my efforts to meet her requirements. And this is actually a lot like how TDD works.

The main thing that comes to mind as I'm fumbling about the desk is that this process isn't particularly efficient. TDD is not really an efficient way to enforce requirements.

So how could we improve this.

Well for one, if my daughter could just come straight out and tell me what she wanted, then I would be able to carry out her wishes with more accuracy. While that probably won't be as thorough as a flow chart and would more likely come in the form of "Ba" for ball or "Wawa" for water, it would certainly help direct me towards the right object.

Natural language is probably the primary mechanism for communicating requirements. More so when you have programmers who do not understand the business, and business experts who do not understand how to write specifications. But while useful, natural language isn't always perfect: regardless of how sophisticated their grasp of language it can often be ambiguous or incomplete.

To truly grasp the requirements, being told what is expected isn't enough - you must have a thorough understanding of the problem itself. My daughter knows exactly what she wants because she wants it! The business expert knows exactly what he wants, because he understands the problem and the business system inside out.

So how do we get from the mind of the person who understands the problem, to the implementation of the process?

The gap will forever exist so long as we have programmers who don't understand the business, encoding misunderstood requirements into low level machine code that is validated only by some tests, which are also encoded by programmers in a desperate last attempt to get the requirements right.

Closing the gap means having less tech-savvy programmers and more business-experts who can automate the things they constantly think about and understand themselves. Workflow platforms, domain specific languages (DSLs) and intentional programming are the tools that enable those people to translate that valuable knowledge into automated processes.

And when your system consists of high level, domain centric, workflow oriented commands such as "When the order price hits the market price process the order" - do you even need tests to validate that this meets the requirements? These commands are the requirements.

This, I think, is where the future of programming lies - business driven development, not test driven development.