Recently, I was in some conversations about development practices.  I believe the methodology used in a technology company has a huge impact on the quality of the product.  I drew up a little diagram to show the differences under ideal conditions.  To be as fair as possible, I had the product launch on the exact same date.  This is not a look at specific coding practices, but rather how the product is defined and built.

The main difference is that in the waterfall approach the specification is heavyweight and goes through as many details as possible.  By doing this, the development effort can be reduced to only 10 units.  This is because all of the decisions are made up front.  QA and Acceptance takes a little longer because there is a dark period where the engineers are working and you have to validate that they actually built to spec.

In the iterative model, there is no dark period.  Because the spec is lightweight, it doesn’t answer all of the questions.  It forces the product manager to work with engineers the whole time.  It forces the engineers to make decisions in the middle of development, which means they will have to redo some of the work.  This is why the development is 14 units rather than 10.

The key question is:  Which product will be better?

My strong opinion on this is that the latter model will yield a vastly superior product.  The reason is that it is impossible to make good decisions up front.  You have to see it all in action.  You have to touch the product and use it to make good decisions.  Plus, no one is perfect.  We all make bad assumptions, bad decisions and use faulty logic.  Being able to change your mind helps you avoid painting yourself in a corner with bad decisions early on.

Additionally, the interaction between engineers and product managers often yields a much more creative outcome.  Engineers are creative people if given a chance. I would state that the idea of having to “redo” something is not a negative.  It allows you to refactor code and learn from mistakes.  At the end of the process, everyone has been part of the process so acceptance is de-facto finished and only QA remains.

I strongly suggest you examine your practices and see if you are doing the waterfall approach.  Do you really think that heavy specification is the right use of your product managers time?