3 ms·
1. That was about 40 years ago when the waterfall process was state of the art. Modern, iterative processes are much more flexible. 2. The loss of productivity
by svachalek 14y ago
1. That was about 40 years ago when the waterfall process was state of the art. Modern, iterative processes are much more flexible.
2. The loss of productivity levels off as the team size increases. Going from 50 to 100 developers is not the same as 1 to 2.
All said, I expect some loss of productivity is inevitable due to context switching and communication overhead but it isn't necessarily a major loss.
- seanmcdirmid 14y agoIn software, there is still economy in scale of a person's time. Throwing more people on a project is still detrimental even if you use something like Agile. It is a major loss. The easy way to combat this is to have longer timelines for projects, or, if necessary, crunch periods followed by more relaxed recharge periods.
- eliasmacpherson 14y agoPretty sure waterfall was never state of the art, rather an example of what not to do [0]. It's often held up as a straw man argument in promoting 'agile'. Brooks' book emphasises prototyping, and 'build one to throw away, you will anyway' which isn't 'waterfall'. Brooks' book also clearly demonstrates that applying a dumb formula derived from the number of programmers doesn't predict the output, and using such a formula to estimate a project's timeline doesn't positively affect the project's outcome. It's main argument is that programmers added late to a project will actually cause it to take even longer to complete. Brooks' book is remarkable - a lot of programming lore and culture originates there or is popularized by it. I'd compare it to casablanca or citizen kane rather than dismiss it out of hand. [0] https://en.wikipedia.org/wiki/Waterfall_development https://en.wikipedia.org/wiki/Waterfall_development