The author describes the software development as a creative process. Most managers and even many CompSci researchers thought it was mechanical with potential for automation and assembly-line type guidance. He wisely contradicts that in a way that I hope was to help us all out by putting reality in management reader's heads.

I used to think one person did waterfall followed by other models (eg Spiral) realizing initial work usually failed and is rewritten. Now I know it's the opposite: waterfall author knew requirements or design would require rewrites. Even made new diagrams for it. Diagrams most of us never saw while ideal model was plastered everywhere. He underestimates how difficult coding part can be but his claims still proved out with methods like Cleanroom and Correct-by-Construction that kept coding structures simple. Almost all defects happened outside of coding and coding changes were straight-forward.

The documentation chapter is pure gold. Managing scope, preventing excuses during failures, ensuring everyone is on same page, rules to keep it consistent even by halting development, wisely noting maintenance/rework phase is horrible enough that docs are a necessity, and handing off system to cheaper, ops people. Those particularly stood the test of time.

In one section, he recommends implementing something to get the process started even if one doesn't know what they're doing. That's to avoid paralysis by analysis and give something tangible to start with. Ironically, "modern" and anti-waterfall methods recommend exactly that.

The simulation part is tripping some people up and a weird read. People take it too literally. What I'm seeing is a call for prototypes that explore some of the user interface, key calculations, structure, I/O, and other trouble spots. The stakeholders each review a bit of this to spot early requirements and design problems. The next section mentions feedback loops that do the same thing which collectively result in buy-in by those paying. Just shows he wisely considered a critical human factor that led to many project failures later on.

So, it was a short and delightful read whose advice should've led to many successful projects and hastened arrival of more Agile methods. Instead, people cherry-picked his points and even slandered him in subsequent work. All kinds of disaster followed.

Least I know now that the real Waterfall was designed to prevent that and probably would have most of the time. So, props to Dr. Royce for being one of the giants whose shoulders we stand on trying to make IT great. Well, should've stood on for many. ;)