Tagged with: Backstory • book • brooks • design • mythical man month • waterfall
Software projects are about humans… They’ve always been. During my study, I got inspired by Barry Boehm’s Theory W, everything Fred Brooks has written, Tom DeMaro and Tom Lister, and Alistair Cockburn. Actually, “The Mythical Man Month” (affiliate link) by Brooks is still one of my all time favorite classics.
That is why I was excited at the opportunity to read the new book by Frederick Brooks “The Design Of Design” (affiliate link. Disclaimer: I got a free review copy). This book contains 20 essays and 7 case studies about the design process. Although it is written by a computer scientist, it tries to appeal to the design of artifacts in general; as design in the construction of something, not as in how something should look and feel.
I especially liked the essay called “What Is Wrong With This Process?” Yes, it the old discussion between waterfall approach and iterative design.
Brooks is on the iterative side: “Even if the goal were fixed and known … design would still be iterative, because the constraints keep changing.”
What I found great about his treatment of the topic is the focus on the persistence of the waterfall model. Even in the original paper in which Royce described the waterfall approach, the author described the model to point out to its deficiencies. So how come we still talk about it?
Brooks makes the connect to the Rational Model by Herbert Simon. It’s a problem solving paradigm that still dominates in the field. Some people claim that the “design everything first and than just build according to design and never change it” paradigm is helpful for beginning designers. It’s far more easier to explain and to grasp than the ugliness of iterative approaches. The author doesn’t agree. The elegance and straight forward simpleness should not be the argument to use a process that is different from effective practices. He explains that novice designers are perfectly capable of understanding an iterative design practice on intuition.
By a stroke of coincidence at the same time I read a blog post by Lyssa Adkins, an agile trainer. She just had taught here first class of people that had no idea what waterfall is…
“I said, “Who here knows what I’m talking about when I say ‘waterfall.’” No one spoke. I quickly explained waterfall … and one of them piped up, “Well, that’s just stupid. Who would ever choose to work that way in the world we live in?”
So it seems, Brooks is right.
But that I already knew from “The Mythical Man Month”.
Bas,
You bring out a critical point. “Why is the Waterfall paradigm persistent?”
The US DoD’s 5000.02 requires spiral, iterative, and incremental development processes. We are mandated to plan programs in increments and rolling waves within those increments. Within those rolling waves, Work Packages are only allowed to cross one accounting period (maximum 60 days, which is short for us).
I’d conjecture the source of the problem is the missing processes for “performing” the project management activities that are mandated in our EVM Systems Description, also mandated by the Defense Contract Management Agency. They provide, along with the National Defense Industry Association’s Program Management Steering Committee’s guidance.
The much bigger question is why would any rational person use such an approach?
Glen,
I think the choices for waterfall are more emotional than rational.
Hi Bas and Glen,
It is one of my favorite exam questions to my students. It seems so rediculous to “fall” for the waterfall develepment process. Were they all dummies? No, in 1980 Boehm had discovered that errors are more expensive when found later. (He stated a factor of 10, I once measured a factor of 7 in a big insurance company.
At those times, programs last for more than3 years, – AND – requirements seemed to be fixed.
It seemed to be a good idea to have as many errors removed during the various phases. There exists a number of 43% of total errors appearing already in the analysis/design-phase.
We all know that we are constantly trying to hit moving targets. And there are hardly three years programs schedules left. Maybe in DoD, but not in the general software community.
So it seems a strange decision nowadays, but there was “raison” at the time being observed.
Hi Hans, thanks for this insight. Now all is left is “why is it so persistent?”