How we got screwed in the first place?

The waterfall model was invented in 1970.
The founding document of the waterfall model, created by Winston W. Royce, included two figures: one of the model itself and a second illustrating the major problems inherent in the model, or the reasons not to use the waterfall model.
Winston’s waterfall method tried to address” Cone of Uncertainty” problem by fixing functionality upfront and got it all wrong – and then he mentioned that in the same article, second page: “The  required design changes are  likely  to  be so disruptive  that  the software  requirements upon which  the design  is based  and which  provides the  rationale for  everything are  violated.  Either  the  requirements must  be modified, or  a substantial change  in  the design  is  required.  In effect the development process has returned  to  the origin and one can expect up  to  a  100-percent overrun  in  schedule  and/or  costs”.

Now something completely different?
(next paragraph from Wikipedia)
Henry Gantt was born in 1878.  In 1887, he  joined Frederick W. Taylor in applying scientific management principles to their work at Midvale Steel and Bethlehem Steel company. In his later career as a management consultant, following the invention of the Gantt chart, he also designed the ‘task and bonus’ system of wage payment and additional measurement methods for work efficiency and productivity.
Gantt designed his charts so that foremen or other supervisors could quickly know whether production was on schedule, ahead of schedule, or behind schedule. He describes two types of balances:
  • the “man’s record”, which shows what each worker should do and did do
  • the “daily balance of work”, which shows the amount of work to be done and the amount that is done.
Gantt charts became extremely popular within waterfall community, as they truly believed that you can solve software engineering problems using 19th Century methodology designed for blue colors workers.
So, how we got screwed?
Gantt charts and waterfall eventually created “some” problems:
  • SW development seen as blue color work, that lead to
  • “Caste development hierarchy”: requirements, system architect, sw. architects, coders, testers, which eventually lead to
  • Moving testers and coders to off shore (since nothing can go wrong), which lead to
  • More management overhead and more paper work, which lead to
  • Less willingness to change any requirement, which lead to
  • SW development crisis

In my next blog post, I will shortly explain India’s “triangle” business model, and why this model typically leads to big trouble. I will then cover how I approach the same issue (about 6 years ago), working hard with our outsourcing partner – which has lead to the long lasting collaboration and great commercial success of our product.

Leave a Reply