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