Demo Driven Development

Last week a few folks in our team including myself worked towards early demo of important VS Orcas features to our high management. The demo went well. The bits were not demoware, they were real code checked in into the real Orcas branch since we do not normally write code solely for demo purposes. We may implement a few isolated temporary shortcuts (a few lines of code that's it), but if feature is not ready, we simply don't demo it. This means good demo requires proper development schedule. When you are developing a new product, it may be important to have 'demo ready' milestones. At the end of the demo milestone you should be ready to demo a good set of new features to your management and/or customers.

If you are using TDD, you may want to keep adding new test cases in such a way so at certain point you will have a compelling set of features implemented (and tested) so you will be fully ready for the demo.

Road to the demo does not deviate much from normal development since people typically want to see most important new features working first. You want the same since those features usually most complex and require most significant architectural changes. Otherwise you would have implemented them a a previous release, right? Thus you probably should be implementing most complex and interesting features first anyway.