Reflections on a waterfall

I recently re-read Tom DeMarco's 1982 classic Controlling Software Projects: Management, Measurement, and Estimates. It is interesting how little changes in almost 20 30 years (wow). One passage in particular intrigued me:

Software developers may indeed resent the idea that an empirical projection approach could be meaningfully applied to their work.  It implies that yet another area of anarchy has begun to succumb to order.  Human beings love anarchy, in limited doses, and regret its passing.  The more order a manager introduces into the the development process, the more he or she ought to consider ways to reintroduce small amounts of "creative disorder" (brainstorming sessions, war games, new methods, new tools, new languages) as a means of keeping bright minds involved.

I picked up the book again because I remembered reading something -- years ago -- about how someone did a study that underestimating tasks actually caused them to take longer -- or at least thats how I remembered it. I'm a lot more careful with believing (or assuming) causation these days, but the argument seemed perfectly logical and I can say unscientifically that I owe much of my on-time percentage to being realistic with the estimates and the staff (even with fixed deadlines). For anyone that happens to know the study or the book, I'd love if you let me know.

In either case, it was a pleasant surprise to pick back up some DeMarco, and it was remarkable how little of it has been changed by nearly 30 years of new technologies, processes, and the like.  For a few, he even has some brilliant predictions:

While an ansynchronous implementation would be in many ways the most natural one (that is, most closely related to the underlying perception of the requirement), present day technology discourages it.  ....  I believe that this practice will change drastically during the 1980s: By the end of the decade, we'lll be routinely building systems with a maximum of asynchronism, rather than the minimum.

Clearly, the web pushed asynchronous development far past what DeMarco would have predicted, but it was certainly helped along quite a bit by object oriented methods, which would take several years after he wrote this to come into vogue.  You cant write a tech book and expect all of it to stay relevant (it wouldn't be technology if it didn't change), and clearly there are some outdated sections.  Much more interesting are the sections that should be long-ago defunct but aren't.

In 1982, the software development lifecycle at any respectable dev shop was based in the waterfall method (heavy design, then dev, test, etc.).  The term "Agile" wouldn't be introduced for another 20 years (although Boehm -- who wrote the introduction -- would introduce some papers on spiral processes, a predecessor of the Agile movement, a few years later).  As such, you might expect a great deal of the Waterfall-centric procedures and suggestions to become outdated and irrelevant.  Not so. Agile and iterative development don't much change the core of message that a process should be repeatable, measurable and, as he notes above, predictable.

I wonder how many of the other tech books I've read recently will last on my shelf nearly as long.