Why do most gov websites look like they were created by someone's 10 year old nephew yet cost millions to make?
— Steve Dekorte (@stevedekorte) December 29, 2011
I think this aptly summarizes the results of a waterfall methodology.
- You wrote a lot of requirements, not fully understanding the actors or their use cases.
- Your vendor implemented those requirements because they were contractual obligations not because they created value for the actors.
Another aspect is the damaged or virtually non-existent prototype loop. As the architect Christopher Alexander points out, useful things of value are grown, not built to spec. In software we've gotten this idea that the class of people using, selling or designing the stuff have magical architectural powers when it comes to envisioning what they want. This is not often the case.
ReplyDeleteThe real world analog is designing a house. I think I know what I want in a house, and I do deserve input into any house I'm paying to have built. But if I thought I could manage the entire design and engineering process up front and then just hand it to the builders, I'd probably end up with a pretty sorry house. On the other hand, if I were to work iteratively with a group of skilled architects, engineers, and designers -- planning for changes and growth up front -- I might just end up with a really nice home.
Users, architects and designers who fail to recognize that this must be an iterative process of unfolding end up in trouble, whether building houses or software. And in a business sense, this iterative process actually saves money, because things are done right, problems are spotted early, etc. The costs are front loaded effectively, rather than wastefully, as in a fiat, non-iterative process.