TMMM: Plan to Throw One Away

Opening with a dramatic photo of the infamous Tacoma Narrows Bridge, the central theme to this chapter is that it’s hard to get it right the first time so plan to complete a project twice. Drawing parallels to the chemical engineer’s need to prototype processes before scaling them up to production, it is suggested that the same be done with software. That is the usefulness in the first version isn’t so much the finished product but the feedback it generates.

Not only are changes in objective inevitable, changes in the development strategy and technique are also inevitable. The throw-one-away concept is itself just an acceptance of the fact that as one learns, he changes the design.

– Federick P. Brooks, JR

The lengths one must go through when the great waterfall process reigned supreme. Nowdays, instead of throwing one away feedback is sought as early as possible and incorperated into the development processes using methodologies such as agile. That’s not to say prototyping isn’t a thing, but it’s a tool to be used where appropriate - not a rule of thumb.

Eventhough the proposal to always throw one away isn’t very helpful, this chapter shows that even back in the 70s problems with the waterfall model’s ability to respond to change were known. I found it a really interesting read for historical curiosity. To see the problem explored and suggested solutions hints at the origins of some of the current day standard development practices.