The Power of X-Driven Development

Test-, Behavior-, and Readme-Driven Development are not just about creating one code artifact before another. It’s not simply eating your carrots before your peas, or putting on your shirt before your pants. These methodologies are powerful; they deeply affect the final structure of your code:

If you just sit down and code, you will find a workable solution quickly. Your program will be optimized for prototyping an idea, but it will also be a dirty mess.
If you write a handful of unit tests before coding, your program will be optimized for further testing.
If you draft some docs before coding, your program will be optimized for clarity and understanding by other developers.

There are many different ways to approach a piece of code: Interface Driven Development #1, Interface Driven Development #2, Domain Driven Design, Statecharts, CRC cards, UML Diagrams. The list goes on.

There is no clear *best* approach; the right approach depends on the situation, the existing codebase, the size of a team, familiarity with different tools, and level of discipline.

But if you are writing a program that you intend to sell or deploy in production, I’d argue that the *worst* possible approach is to just sit down and start coding.

Back