More is Less in Brooksâ€™ Law Software Development Scenario
Avoid the â€śSalvageâ€ť Situation with Proper Analysis
Brooksâ€™ Law: A principle in software development.
â€śAdding manpower to a late software project makes it later”.
The principle was coined by Fred Brooks in his 1975 book The Mythical Man-Month presenting that there is an incremental person who, when added to a project, makes it take more, not less time.
Brooks himself admits that his law is an outrageous oversimplification but it does deliver the basic message that more does not necessarily produce more when it comes to software development.
Brooks shares an explanation of why it works this way: New people added to a project require â€śramp upâ€ť time.
- Project newbies must be given time to become productive.Â Software projects are usually wrought with complexities that newbies must be educated on.
- What has preceded them
- What is expected
- What the areas ofÂ expertise on in the code base
- How the project is beingÂ approached
This education process requires diverting resources that were productive before the newbies, who are not yet contributing, came on the scene.
- Increasing the number of people on a project also increases communication overhead. Doubling theÂ team causes a four times increase in the number of conversations it takes to manage the project.
- Bugs the newbies may contribute further deteriorate the process.
These factors reduce the overall productivity of the project and can move it even further from completion.
The Law is often the excuse.
Sometimes Brooksâ€™ Law is â€śthe excuseâ€ť for missed deadlines and busted production schedules â€“ â€śdespite management effortsâ€ť.Â Instead of using this as an excuse, the better approach would be to use the Law as the bases for potential solutions to project tardiness with the following points in mind.
Point One: Keep in mind that Brooksâ€™ Law generally applies to projects that are already late.
Success has been proven in salvaging projects or bringing them back under control by adding resources early in the process. Good project managers can recognize indicators in projects that are headed down the late path and take action in time to â€śsaveâ€ť them.
Point Two: Are scheduling mistakes the culprit? Perhaps the schedule was â€śtoo optimisticâ€ť â€“ setting the project team up for disaster from the beginning? Correcting the schedule as soon as the failure is noted is the best way to reel the project back in and create a reliable timeframe for completion.
Point Three: The newbies themselves have a tremendous impact on the projectâ€™s timeliness.
Are they experienced? New to programming? New to the process? New to your company? New to their role? All of these factors must be considered. Some consider that circumventing the Law simply requires adding more people than needed â€“ capacity compensating for the training and communication overhead. This theory is totally dependent on the characteristics of the newbies relative to the questions noted above. Of course, good programmers, skilled in the requirements at hand, can be added with less training overhead. Also consider that people can be added to do other project-related tasks – such as quality assurance or documentation â€“ with minimized impact to ramp-up times.
Point Four: The impact of the Law can also be minimized by good management and development practices and new software development and documentation tools â€“ including continuous integration, test first design, iterative development. These practices reduce the communications complexities and allow for the team to scale much more effectively. New software development and documentation tools help to minimize ramp up time and simplify newbies integration into the real project work. Design patterns that define the rules that programmers follow â€“ allow work to be distributed more easily and clearly because the pattern enables the entire team to execute within a framework. The pattern uses a standard language, and provides consistency and scalability.
Point Five: Good segmentation is critical to communications. By segmenting, problems are disseminated to smaller teams. Broader responsibilities such as systems integration, are solved by top-level teams. Keep in mind that this works only when segmentation is done correctly initially. If it is botched from the onset, the segments can actually make productivity issues worse.
Politics and development donâ€™t mix.
There is another factor that can alter the effects of the Law highlighted by author Karl E. Wiegers in Creating a Software Engineering Culture:Â The social and political aspects of the work climate.
This factor can be detrimental to the effectiveness of individual programmers and the project team as a whole. The presence of a â€śheroâ€ť can poison the dynamics of a good team. Wiegers presents that a team of ordinarily-skilled individuals can be more consistent in delivering timely results than a team that depends on heroes to lead with extraordinary efforts.
Unfortunately, it is a common strategy.
In spite of Brooksâ€™ Law, managers frequently use additional resources as their salvage strategy. Recent statistics showed that about half of the managers of runaway projects* attempted to bring their projects under control by adding staff.
*Runaway projects are those that exceeded their planned schedules or budgets by more than 30 percent.
Brooks got it right with his Law.
There are those who believe that Brooksâ€™ law is flawed. After all, ten people can pick peaches ten times as fast as one. This theory isnâ€™t supported by the way software development works. To follow the peach picking theory, the project at hand must be easy to partition into isolated independent tasks. As far as peach picking goes, this works because the tasks require little communication and coordination between participants. Software development project success, however, is completely dependent on communication and coordination between developers and managers and is therefore not partitionable.
Avoid Brooksâ€™ Law with project analysis.
While most project managers would kill for extra resources that they believe can make or break project success, far more factors must be considered to understand if extra resources will help or hinder the project.
The points noted in the body of this article provide a good foundation for determining if adding resources would be effective in project salvaging situations. But the best advice is to find a way to avoid putting yourself in the â€śsalvage positionâ€ť by completing a project analysis at the projectâ€™s onset – even before the development plan is laid out â€“ to provide each project with its greatest potential for success. Potential problems can be avoided by instituting a solid, proven framework that is properly documented with agreed upon change management and risk management processes that ensure the project is a priority for everyone involved â€“ including critical decision makers.
The project analysis and planning allows the unknown to be practically eliminated from the project scenario. There is a process for dealing with change and risks are mitigated through testing regimens.Â All project details and impending factors can easily be identified and addressed â€“ making sure that the goals, needs and challenges that could impact the project are revealed, articulated and understood by all project participants and decision makers.
The moral of our post: It is good to know the best route for escaping project situations gone bad, but it is even better to know how to avoid becoming a victim of runaway projects in the first place.