Re:Books I recommend to my software engineering students
by Jtsummers on Friday April 24, 2020 @10:55AM
(#22968594)
Royce didn't set it up to disparage it. He set up his idealized flow and then proceeded to add details that he believed were critical to making it work. In the end, what he proposes is what most people understand to be Waterfall but with some extra details:
- Feedback loops (because problems or deficiencies will arise)
- Involving the customer (because you don't want to spend 12-60 months building the wrong thing)
- Build a prototype (good advice)
- Document, document, document (he thinks 1500 pages is a good target)
The only thing practitioners seem to have taken away is that last bullet. He still made a strong distinction in his model between analysis, design, and implementation. Though, to be fair, at the time "programmer" was more of a technician level and design often involved making detailed designs like flowcharts and such that could be more easily translated into code. These days, design and implementation are really tangled up, and the documentation is awful an non-actionable (I've been on those teams, it's nightmare inducing). People think prose can replace a diagram, so they fill out their 1500 page quota with lots of words but no clarity.
The name came later, and was enshrined in a DOD standard by people who couldn't read past the first few pages. So they entirely missed the lessons learned he was trying to apply to it.
- Feedback loops (because problems or deficiencies will arise)
- Involving the customer (because you don't want to spend 12-60 months building the wrong thing)
- Build a prototype (good advice)
- Document, document, document (he thinks 1500 pages is a good target)
The only thing practitioners seem to have taken away is that last bullet. He still made a strong distinction in his model between analysis, design, and implementation. Though, to be fair, at the time "programmer" was more of a technician level and design often involved making detailed designs like flowcharts and such that could be more easily translated into code. These days, design and implementation are really tangled up, and the documentation is awful an non-actionable (I've been on those teams, it's nightmare inducing). People think prose can replace a diagram, so they fill out their 1500 page quota with lots of words but no clarity.
The name came later, and was enshrined in a DOD standard by people who couldn't read past the first few pages. So they entirely missed the lessons learned he was trying to apply to it.