DIMINISHING RETURNS IN SOFTWARE DEVELOPMENT, AGAIN
"Arguing in My Spare Time," No. 2.08
Arnold Kling
June 14, 1999May not be redistributed commercially without the author's permission.
Index
The June-July issue of "FastCompany" magazine contains an interview with Michael Cassidy, co-founder of an innovative Web search engine. He says that if you divide the estimated market value of his company by the hours spent by developers, the resulting figure is $10,000 of value created per developer per day. He goes on to say,
"Whenever we consider how many resources we should devote to improving a product, we ask ourselves, ‘Do the benefits justify an investment of time by someone who’s worth $10,000 per day?’"
He explicitly states that this analysis is used instead of evaluating enhancements as if the cost were the hours required times the hourly salary. The latter figure would be much lower. Even at $150 per hour and a 10-hour day, a developer would cost only $1500 a day.
I would argue that Cassidy’s policy reflects the phenomenon of extreme diminishing returns that was the theme of the previous essay. Without diminishing returns, it would be irrational to use a $10,000 per developer-day hurdle test when the cost of a developer-day is no more than $1500. If $1500 were the cost, and there were constant returns to scale, then it would be rational for Cassidy to approve any project that has a value over $1500 per developer-day. This would lead him to approve many more projects and to add more developers.
Instead, Cassidy is acting as if one should treat the number of developers as fixed and allocate developers to projects worth at least $10,000 per developer-day. In conventional economic jargon, he is saying that the "shadow price" of a developer is $10,000 per day. This is rational if there are sharply diminishing returns to adding new developers.
An implication of diminishing returns is that managers should treat the shadow price of software developers as being above their wage rate. Cassidy’s policy is a dramatic illustration of the difference between the shadow price and the wage rate.
In addition to a high shadow price for software developer time, the existence of diminishing returns has other implications for managing the software process.
In many companies, the larger the software project, the greater the prestige and visibility with upper management. To the extent that this occurs, it creates the wrong incentive. Given diminishing returns, large projects are most likely to fail (in fact, I have seen data that indicates that 25 percent of large projects are canceled, compared with a 15 percent cancellation rate for small projects). Even if a large project is not canceled, 30 developers working on one project are likely to produce much less than if they were working on five projects.
Estimating the cost in terms of staff-months tends to imply that the are no diminishing returns. This can be particularly dangerous if the estimates are built on a "bottom-up," component-by-component basis. The cost of the project may turn out to be much more than the sum of the cost of its components.
Another illusion that staff-month estimates foster is that of the ability to achieve a linear trade-off between staff size and deadline. This fallacy is the point of Brooks’ famous "mythical man-month" essay. For example, suppose that we estimate that a project would take one year to complete with a team of 5 developers. If we represent this as 60 staff-months, someone may set a deadline of 6 months and expect 10 developers to complete the project. This is completely inconsistent with the principle of diminishing returns.
Other things equal, a project will be done more efficiently if a smaller team is given more time than if a larger team is given a shorter deadline.
Use development methods and design techniques which unbundle software projects, allowing people to work on separate pieces while minimizing overlap and potential conflict. Unbundling helps to alleviate the impact of diminishing returns.
Object-oriented programming is one technique that is supposed to facilitate unbundling. It does so by creating independence between different parts of a software system. In theory, the programmer who uses another programmer’s object-oriented code does not need to know the internal operations of that code.
Database normalization is another practice that helps facilitate unbundling. Suppose that you keep information about customer orders and customer billing addresses. Keeping all of that information in the same data table is likely to cause programs that use the data to have unintended side effects. Separating the data into two tables linked by a customer id is a form of unbundling.
This may seem a bit counter-intuitive. However, the more staff you put on a big project, the bigger will be the penalty from diminishing returns. Conversely, if you put a large team on a small project, it will be over with relatively quickly, and whatever penalty you pay in terms of diminishing returns will be limited. Of course, the optimal approach probably is not to put a large team on a small project, but to have that same number of developers work on multiple small projects.
DeMarco and Constantine, in their book "Peopleware," claim that there are some people who help to make teams more cohesive and productive. If so, then these "good apples" help to reduce the extent of diminishing returns and they should be valued highly. By the same token, in a diminishing-returns environment, bad apples have a higher shadow cost than simply their own wage rate.
In conclusion, the mysterious problem of diminishing returns may be one of the most important things for a manager to understand when allocating staff for software projects. Michael Cassidy’s policy illustrates just one possible adaptation.