| Demo driven software development oddly enough * A demo is a thing you can show. The first demo is usually - the program will compile, run and print "hello world"
* A demo is a contract between stake holders* Demos happen frequently. For a developer each day, for a team each week, etc. Why does this help? A demo, actually showing something, is the only enforceable token that commits both part to the contract. In that way it is almost a currency. No stakeholder, whether manager, sales or developer can argue - either the demo was met, or not or was not clear. This is much like sprints, test-driven, but a demo has the contract aspect. Demo-driven reduces many of the causes/motives for over-engineering.
* Is the over-engineering bit in the contract? Why not?
* New function requires a new contract so no more last minute changes. (Been there done that).
* Stakeholders gain experience designing demos.
* Demos are adaptive. They provide tactile feedback. My 2 cents |