Fred Brooks wrote a seminal book titled “The Mythical Man Month” in the 1960s. This book chronicled the challenges that IBM faced developing the operating system for their 360 family of computers. In simple form, Brooks’ law is:
“Adding manpower to a late software project makes it later”
– Fred Brooks
Many managers, frustrated by how long it can take to develop software, often ignore Brooks’ law and turn to the only variable they think will help – how many people are working on the project. The logic goes something like “If 50 people can produce 20 features a year, surely 100 people can produce 40!”. Often these are business people and financial officers that are removed from the development process. Furthermore, they are extremely proud of the ROI analysis they’ve done to show that if you double the number of features per year, you can generate more than enough revenue to cover the additional expense, and growing profit! This logic might makes sense in some disciplines that are labor intensive with a low training threshold, but does not work in software development.
So I offer this quote to managers:
“Those who cannot remember the past are condemned to repeat it.”
– George Santayana, Author and Philosopher
When I first read about Brooks’ law many (many!) years ago, I attributed the slow down to the impact that new people have on the existing staff, i.e. you take capacity away from trained, productive people to onboard and teach the new staff.
Kanban gives us a different insight into the slow down when adding new people. In addition to the lowered productivity of the existing staff, the new people also disrupt the “flow” of new work in several ways.
First, if the continuous build system works at a certain rate of software check-ins, if you double that rate the system may no longer be able to product software builds on a predictable basis. Just like the highway that can handle 10,000 cars per hour, if that doubles to 20,000 it actually becomes less efficient at the time it is expected to handle more.
The second impact of new developers is an increase in defects. This is not due to ineptitude but more likely a lack of knowledge and limited access to an automated regression test.
How to cheat Brooks’ Law
Opponents of the law state that it is an oversimplification and there are exceptions. I believe Fred Brooks himself would agree, but that does not mean it should be ignored.
There are several methods that I have used in the past to cheat Brooks’ Law. All of these will be met with resistance from your product managers, since they do not involve adding people to feature/function development! I will share a few here for those of you brave enough to implement them.
DevOps – Consider adding your new developers to Development Operations to increase the capacity of your infrastructure to support more developers.
Support Tools – I’ve employed this very successfully in the past. The new developers can learn the system from a database perspective and build tools that make it easier to find problems. The existing team will love them and your productivity will improve.
Testing – Similar to support tools, this will allow new staff members to learn the system from a functional and database perspective without generating code that may destabilize your integration effort.
General purpose code – As you add developers to the mainstream coding process, try to identify general purpose frameworks that will help the project overall, but do not require significant domain knowledge. The new staff can apply their industry knowledge quickly as they begin to learn your application domain.
Comprehensive on-boarding program – An effective on-boarding program can minimize some of the negative impact of on-the-job-training that normally occurs. Training on the application and development process done outside of the development teams will reduce the loss of productivity. This tends to work better when you are hiring in large numbers.
We all know that it is necessary to grow your development staff to increase capacity, but please keep Brooks’ Law in mind as you do so. Do not expect that you can double your productivity by doubling your staff. Apply your new resources selectively and allow them time to learn your environment.