In the project described previously, data collected showed that six developers were doing over 90% of the work on the project. Even more striking was that just one of those six was doing 40% of the projects work on her own. The other 80% of the developers were doing nothing other than to slow down the 20% who were doing the work.
Another flawed assumption in the SMFs is that they assume there is no overhead associated with increasing the number of people on the project. This overhead cost due to increased project size is a central theme of Frederick Brooks classic The Mythical Man Month.
Each person added to the team has a cost in overhead time that gets applied to all of the other team members. Status meetings are a good example. A project team of 6 people can have a weekly status meeting over lunch. With 30 people, it becomes an all day affair as in the previous example. In observing this project, the ultimate irony was that at the status meetings each person who contributed real work could describe what he did in a couple of minutes, while those who did nothing typically spent ten minutes describing what they did not do.
This brings us to the 8-Man Rule:
The maximum number of people that can be on a discrete project without incurring significant overhead is about 8.
The 8-person figure is a general rule of thumb figure derived from experience. Once discrete projects start to get larger, then the value of additional people one the project drops precipitately.
The 8-Man Rule does not preclude out larger projects but rather dictates how they have to be approached. Obviously there are projects that will require more than 8 programmers in order to be completed within a reasonable period of time. Large projects need to be subdivided into smaller discrete units in order to conform the 8-Man Rule. Larger projects require much more up front work and are far less tolerant of winging it than smaller projects. In any event, the 8-Man Rule is in direct conflict with the SMFs.
There are a number of factors the SMFs do not take into account at all. In the project above, the physical work environment was one of the most significant factors in delaying the project. Putting this particular project team together in one room was a disaster. While the team room concept works extremely in certain situations, it is highly sensitive to the composition of the team (in regard to both personalities and individual contribution) and the type of project.
In this case the team rooms was an overcrowded tenement created by accident rather than through a plan (simply the result of lack of office space); the project was not of a nature suited for a team room; and the people mix was not a good one for working in an intimate environment.
This project was an unusual case where the company was willing to spend whatever it took to get the project finished. A new concept comes into play when using the SMFs as the basis for project management and cost is a consideration.
The Principle of Software Cost Reduction (PSCR) flows directly from the SMFs. The PSCR states that the key to reducing Cost of Software is to reduce Hourly Cost Per Worker. The PSCR can easily be derived from the SMFs above by mathematical substitution, giving:
Cost of Software = Software Produced x Hourly Cost Per Worker.
The PSCR proves that for any give software project, the cost is linear based upon the Hourly Cost Per Worker. Thus the key to reducing software development costs is to reduce the Hourly Cost Per Worker. To reduce the hourly cost per worker, one needs cheaper programmers.
Industrys current focus on cheap programmers flows naturally then from the PSCR. Due to differences in living standard among countries, there is a disparity in wages between those of North American/Australian/European workers and other parts of the world. This creates pools of cheap labor just waiting to be tapped by industry countries. The problem is how to get at it.
For that there is offshoring and H-1B visas.
The slavish devotion to the SMFs is why we never see the industry lobbying for measures to improve software development productivity. We never see industry call for government funding for studies on best software development practices. We never see industry call for research funding for software development tools designed to produce software more reliably and efficiently.
Instead, we simply see repeated calls for access to more cheap foreign labor, often with mindless platitudes, such as calls to staple green cards to every diploma, and the tired canard about the state of K-12 education. Such is industrys bankrupt state of leadership. The result is an industry whose symbol is the Blue Screen of Death; an industry whose probability of delivering a project on schedule and on budget is lower than the cure rate for most cancers.
The SMFs and PSCR provide management easy-to-understand solutions for developing software. Without the SMFs and PSCR, the key to reducing software development costs is to increase individual developer productivity. To increase developer productivity one has to know the process of software development; one has to be able to take on the corporate facilities bureaucracy to create work environments suitable for software development; one has to take on the HR bureaucracy to get the right people and reward them; one has to negotiate with top management the project tradeoffs among cost, time and features.
This takes highly skilled managers who either know the intricacies of software development or who can delegate to good advisors who do. Under the SMFs, and PSCR, the key to reducing software development costs is to find cheaper programmers. Any anyone with a high school education can understand the cop out of the SMFs.
After reading about the project described previously, you are probably wondering why the company did not apply the PSCR and send the project offshore? The answer is simple: They already had and it was a disaster. The project was part of the recovery from an offshoring nightmare, the aspect of offshoring that rarely gets written about. Still, even after the disaster of offshoring, the company, like so many others, retained its devotion to the SMFs.
Plus ça change, plus cest la même chose.
John Miano is an author and expert on the software industry. He may be contacted via Colosseum Builders.