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.