I am a huge fan of Test Driven Development (TDD). When I think about tests before implementations, I have to understand the observable effects of a system. I systematically think about each aspect of a system, and, if I’m lucky, I will see the gotchas and dead-ends before accidentally coding them. Test driven development helps me ensure a component is properly vetted before development. It is also helped guide me to a new software methodology I call Demo Driven Development.
Demo Driven Development is designing a demo and then building the features it requires. A good demonstration doesn’t need to be convention-scale; some great demonstrations fit in 150 characters. Good demonstrations concisely articulate what a product is rather than presenting a dull list of what a product does. And a good demonstration does not happen by accident. Consider the difference between two well-engineered products: the iPod and Backbone.js.
The iPod was clearly designed to with its demonstration in mind. An iPod requires very little setup and guides you through the few steps necessary. Everyone knows what an iPod is; it’s a fantastically compact and simple music player. Each feature of the iPod is designed so that it is easily discovered and more easily shared with a friend. These two considerations contributed most to the virility of the ipod.
Demo Driven Development is the key to successful product. It focuses engineering efforts on the parts which sell. It equips a marketing team with a compelling pitch. And it helps a user better understand the purpose and methods of using your product. If your product is hard to demo concisely, it is not likely to succeed.