In 1975, computer architect Fred Brooks published a series of essays on software engineering and project management called “The Mythical Man-Month”. These cautionary tales and inevitable realities not only stand the test of time, but also can crossover to many applications.
In this fourth article I will talk about is his essay “Plan to Throw One Away”. The basic theme of this is best quoted by Mr. Brooks himself: In most projects, the first system built is barely usable…hence plan to throw one away; you will, anyhow.
There are a lot of unknowns with any project. Some of these can be reconciled in advance, and others can be dealt with as they come up. When planning the project, as many of these “what-ifs” as possible are identified and plans are made to deal with them. As the project gets further along, however, some of the measures taken to deal with the things that come up can cause the foundation of the project to shift in undesirable ways.
In the end, the project will be completed but the finished product will not be without serious issues. At this point, the natural inclination will be to throw resources at it in an attempt to right the ship. The problem is, the issues are so deep-rooted at this point that the better solution may be to start the project from scratch again with the better understanding of what went wrong and how to deal with the problems that came up. A better foundation can be laid.
In reality, the decision-makers will tend to try to salvage what is existing for various reasons – including keeping their jobs. The thought of scrapping an expensive project and starting over is simply too daunting and may unfairly reflect poorly upon the project manager..
This phenomenon isn’t unique to programming either. It is very common in sports to see a similar situation when a highly-paid draft pick isn’t living up to expectations. What usually happens is that the player continues to play because of the sunken cost. The team suffers as a result. Coaches and managers don’t want to look bad by having another player outshine the highly-paid bench anchor even if the team ends up doing better.
If the decision is made to try to salvage a project it is still entirely likely that it will have to be scrapped even after a lot of additional money was spent. Some things just can’t be fixed.
A more modern and pro-active approach that has spawned from this concept is that of “agile programming”. This means that projects are designed to be “refactored mercilessly” and often the first iteration will be a shell of a program, knowing that it is destined to be scrapped. Changes that result can be made quickly and without a lot of red tape and the final version can be worked on with a lot of the uncertainties already worked out.
In conclusion, if you’re dealt a bad hand, what should you do? Hold ‘em or fold ‘em? If you try to bluff yourself and forge on, you could end up losing all your chips.
Sometimes the best long-term strategy is to throw the cards back in and try again.
Written by Carlo Zaskorski
Controls Engineer, Product Manager, and Freelance Blogger
Edited by Shawn Tierney
Have a question? Join our community of pros to take part in the discussion! You'll also find all of our automation courses at TheAutomationSchool.com.
Sponsor and Advertise: Get your product or service in front of our 75K followers while also supporting independent automation journalism by sponsoring or advertising with us! Learn more in our Media Guide here, or contact us using this form.
- The Realities of Project Management: Know When to Hold ‘Em, Know When to Fold ‘Em - December 23, 2019
- The Realities of Project Management: The Project Czar - December 5, 2019
- The Realities of Project Management: The Second Effort - November 21, 2019
Discover more from The Automation Blog
Subscribe to get the latest posts sent to your email.
