The Mythical Man Month
I think I first read Fred Brooks’ The Mythical Man Month (TMMM) during my university days at Cal Poly. It covers a number of topics around software development and project planning, but the central theme, known as Brook’s Law is as follows:
Adding manpower to a late software project makes it later.
The book was first published in 1975–making this an ancient tome in the current tech world. Brooks used extensive observations from his recent (at the time) OS/360 project to illustrate how adding more folks to the projects, rather than speeding things up, continually worsened bad situations.
Adding more people to a project naively seems like it should speed things up and bring the delivery date forward. After all, more bodies can attack more problems, right? This may be true of projects that do not require particular skills, but it is not true where domain expertise is required.
Year after year, at software companies spanning the globe, the same scenario repeats: a project is behind schedule and the teams are overworked. A key customer must be pleased. A conference deadline is rapidly approaching. Too many bugs have been found, and more people are needed to fix them. Groups of engineers with minimally matching skill sets are hired or reassigned and shoved into a project for which they lack experience and history.
This is the story of The Mythical Man Month: Additional overhead caused by more meetings, communication, and management. Magic math based upon the assumption that each additional headcount will bring in the deadline proportionally. Original engineers stretched thin, attempting to both get their own work done and bring the new folks up to speed. Quality suffering as inexperienced folks take on work they don’t fully understand. Project slipping further behind their deadlines. The problems escalating as even more engineers are added to the project.
What To Do?
So what should you do when you find yourself behind schedule and under pressure?
First, do not make it worse! Flailing attempts to magically fix the broken project will compound the problem. Be smart and realistic:
- Take ownership of the situation so that you fully understand what is going on and can make reasonable suggestions before ‘helpful’ people start throwing bodies at you.
- Work with stakeholders to determine the true priorities of the project and reassess your MVP. Cutting scale and/or features is usually safer than adding resources.
- Adjust the schedules to fit reality, but ensure that you have a damn good grasp on the reality of the situation before you do so (avoid wishful thinking).
- Work with the key people/teams to assess exactly where and what type of help is needed, if any, and where you can get it.
- Make realistic assumptions about the costs (in time, additional communication, and distractions) of bringing on additional help.
- Only bring in people with the right skill sets, who are able to communicate effectively with the existing teams. Consider people’s past work, relationships, languages, time zones, etc.
- Everyone will be under pressure to come up with silver bullets to magically bring the project back on schedule, but you must keep the planning rational!
Bringing in additional folks can occasionally work well, primarily when the exactly right folks are added early enough to make a difference. If you have people who have successfully worked in the same domain in the past, are already up to speed, and can seamlessly integrate with the existing team, usher them in! The real questions is: If they are such a perfect match, why weren’t they working on this project from the start?
The Real Solution: Take Control of Your Organization
All of this is a long-winded prequel to where I really want to go with this post, and the next few to follow, on scaling your software development organization.
If you make organizational decisions while under strong pressure to act you will likely produce bad decisions. In TMMM a single project provides the pressure, but it can come from many sources: rapid company growth, quality problems, customer expectations, market changes…
As a Software Engineering Leader you need to be thinking ahead about the next steps for your organization, before the next emergency. Consider all the relevant factors including your people, their skill sets, and your upcoming projects. Put in place a skilled, flexible (but not necessarily large) organization that can respond to various scenarios. Do not allow people who don’t understand software development to coerced you into poor choices. Make a plan for scaling your organization and get started.
In the next couple of posts I will talk about the form of a good plan.