Plan to Throw One Away is the eleventh essay of The Mythical Man-Month by Fred P. Brooks. In this essay Brooks expounds on the idea that system development and change are inextricably linked. Brooks begins the essay by making the argument that in many projects the initial design is replaced as more information is generated. Brooks uses the analogy of chemical engineers bringing a new process to production. ChemE’s recognize the need to prototype and pilot new processes in order to find the kinks. Software projects are no different. Rarely is the first attempt useful to the end consumer, and the usefulness of that first attempt is less in the code than in the feedback it generates. Software development is no different. The initial conceptual design and anticipated technical architecture of a large project rarely stands up to the rigors of the discovery process, and those designs should be learned from and then thrown away. Pilots and prototypes are often used to refine and validate requirements. Translating ideas from user stories, requirements or even use cases into a functional system is a journey of discovery and change.
Methodologies at that include prototypes, pilots or deliver functionality quickly generate change. Brooks drives the home the idea that change is inevitable with the phrase “Only constancy is change itself.” This section foreshowed the value in the Agile Manifesto that states, “Responding to change over following a plan.” On a cautionary note, while some change is inevitable, too much change can lead to a failure to deliver anything. Time boxes are a tool to compartmentalize change so that change does not lead to a failure of delivery.
If change is both inevitable and good (within limits), then both systems and organizations (a type of system) need to be engineered to support and facilitate change. Architecturally, techniques such as modularization, object-oriented design and other processes that foster simplification and incremental change create an environment in which change isn’t avoided, but rather encouraged.
Embracing change fosters and effects more than just the application code and technical environment; the human system needs to be designed to support change. Here again Brooks is a thought leader by espousing the idea that people with broad skill sets create flexibility. In 1991, 16 years later, Tim Brown of IDEO coined term ‘T-shaped people’ (or skills) to express the need to broaden skill sets in order to foster flexibility. Just like embracing application architecture that supports and fosters change, the organization architecture needs to be designed to react to feedback so that the process of development can effectively react to change.
Brooks describes development as a dance that takes two steps forward and one step back. I recently participated in a discussion of application support with a manager of a support team. The manager observed that maintenance gets harder as applications age. Applications, when initially delivered, are at their lowest level of entropy. Not zero because all applications are delivered with defects that must be repaired. As repairs are made the original structure of the application will be disrupted and the newly inserted defects will increase the entropy. Pilots, prototypes, flexible designs and T-shaped people are all steps to improve application delivery that maximizes value and minimizes entropy.
Previous installments of the Re-read of The Mythical Man-Month
The Mythical Man-Month (The Essay)
Aristocracy, Democracy and System Design
Why did the Tower of Babel fall?
Ten Pounds in a Five–Pound Package
September 20, 2015 at 4:20 pm
As Thomas states above, Brooks understood the nature of software development and foreshadowed much of what we now call agile.
Brooks also discussed software defects in this chapter, see figure 11.2 (p. 121) “Bug occurrence as a function of release age”
“These things get shaken out, and all goes well for several months. Then the bug rate begins to climb again. Miss Campbell believes this is due to the arrival of users at a new plateau of sophistication”
September 24, 2015 at 7:35 pm
Excellent additions to the re-read!
A few years ago I gathered data on application size, defect rates and average code base age. Middle aged applications had the best defect to size profile with young applications and older applications suffering from higher bug rates.
September 26, 2015 at 11:55 pm
[…] Plan to Throw One Away […]
October 2, 2015 at 5:34 pm
[…] Cagley‘s recent post “Plan to Throw One Away Re-Read Saturday: The Mythical Man-Month, Part 11”, was a good reminder that while “technical debt” may be something currently on the […]
October 3, 2015 at 11:57 pm
[…] Plan to Throw One Away […]
October 24, 2015 at 11:56 pm
[…] Plan to Throw One Away […]
November 1, 2015 at 12:30 am
[…] Plan to Throw One Away […]
November 7, 2015 at 11:56 pm
[…] Plan to Throw One Away […]
November 14, 2015 at 11:56 pm
[…] Plan to Throw One Away […]
December 5, 2015 at 11:57 pm
[…] Plan to Throw One Away […]
December 14, 2015 at 12:02 am
[…] Essay 11 reply (September 20, 2015) … […]
June 14, 2016 at 11:56 pm
[…] they also have broad levels of experience that can be applied. Tim Brown of IDEO coined term ‘T-shaped people’ (or skills) to describe this combination of specialization and experience. There are a number […]