Software projects tend to run past deadlines and estimates. Like many things in life, if something needs to be done sooner, you get more resources or people to work on it. Counterintuitively in software development however, this can slow a project down in certain situations.
There is a phenomenon is called “Brooks Law” as described by Fred Brooks in his book“The Mythical Man-Month”.The main idea of Brooks Law is simply this:
Adding more people to a late software project makes it later.
Why would adding more resources to a project slow it down? Well, in some ways, it can slow things down, and in other ways, it can speed things up. In this post, we will take a look at factors that can slow down a team and some strategies to mitigate them.
Why is productivity slowing?
We have three factors that can slow down a project when adding additional staff.
- Ramp up time
- Communication overhead
- Small projects and isolated problems
Ramp up time. Every programmer added to a team must be trained and “ramped up”to the project. Typically ramping up means pulling another team member away to help train the new team member. Training and becoming productive on a software project takes a lot of time. Because of this, adding new people to a team in alate project will make the project later until the new team members are productive.
As with any complex project adding more people adds more lines of communication.If a project is behind schedule adding more staff can create more communication overhead at the worst possible time.
Lastly, with smaller projects, adding too many people can cause overlapping work, slowing efforts. At some point you will hit diminishing returns as adding more help slows down the people trying to solve the problem. When a project is small or is an isolated problem, this slowdown is more likely to happen. Take the classic phrase “to many cooks in the kitchen”. So when should we add developers to a team and what should we do if a project is running past hard deadlines?
Start Small
Start new projects with a small senior team with experience in the problem space. A small experienced team can accelerate the project and get it off the ground quickly. Add additional only staff after the code architecture and an MVP are complete. This allows time for best practices such as code conventions, unit testing and integration testing to be established and created. By stabilizing the codebase, we can significantly reduce ramp-up time for future onboarding team members as they can follow a framework of existing code and documentation in the project.
Grow Incrementally
Add only full time, long term, contributors to the team during early stages. When adding staff that can only contribute part-time or temporarily, the project pays an expensive ramp-up and communication tax without seeing the long term gains of a productive full-time contributor. This cost is similar to hiring anew employee to only have them quit soon after, so make sure it's worth the overhead cost.
Once the project is established, add contributors steadily as needed. Factor in ramp-up time for new contributors into project estimates and keep priorities focused.
A small team focused on the must haves > many working on nice to haves early in a project.
Cutting Losses and Ask for Help
Law of nature: programmers are terrible at estimating. It’s just a fact of life. What may seem like only a few weeks off schedule is often a few months. When an established project far off from being completed it is worth paying the ramp-up tax to gain the long term productivity of the project.
If hard deadlines are looming, then if possible, pull in more senior staff from other projects temporarily to help. If necessary hire specialists for the specific critical blocking issues or consultants for tasks that can be off loaded without needing much ramp up time. This can help prevent deadlines from being pushed even further out.
Properly growing a team’s resources is one of many factors for a successful software project. Throwing more people at a project can help but can also backfire in certain situations. Assess the pros, cons, and tradeoffs for your team and project. As always, in software development, it depends.
Top comments (0)