Twentieth Century architect Ludwig Mies van der Rohe, who coined the dictum, "less is more," is known for his simple designs. Interestingly, this concept has proven true time and time again in the software industry. In this column, Linda Hayes explains reasons why simplifying your team when it comes to quantity is so vital and shares some surprising statistics on how team size can affect quality.
You may remember the study of project outcomes from the Quantitative Software Management (QSM) study (www.qsm.com) referred to in a previous column, "Why Subject Matter Experts Matter." By using the same data—that is, the metrics from more than 7,000 projects—but analyzing it differently, QSM's new study is even more interesting. Simply put, they discovered that the more people you add to a project, the lower your per-person productivity and the higher the defect rate. For example, two and one half people can develop 40,000 lines of code in forty person-months and take only twelve calendar days longer than twenty-nine people in 191 person-months can. One reason for the lost productivity? The larger team produced six times as many defects as the small one.
While this is stunning to contemplate (and you should, at length), it is really not news. QSM did the same study in 1996 and saw the same results. Books, articles, and papers have been published—going back three decades—that say the same thing: the more resources, the greater the decline in incremental productivity and quality. As a third-time software entrepreneur, I've consistently confirmed the adage that one $100K developer is worth more than two developers worth $50K each.
However, another implication of this study is more difficult to measure but far more significant. After fixing all the defects, the quality of the code written by the larger group will be much poorer, resulting in long-term increased maintenance costs. It is a fact that virgin code is usually (I hope) well designed and written. But as that code is subjected to changes for adding missed requirements, correcting defects, and generally being passed around from one developer to another, it becomes an unstable, confusing patchwork.
Since software spends the vast majority of its useful life in maintenance, getting the first version out faster at the expense of all future releases is a bad business decision. Think about it. Throwing bodies at the schedule today will actually increase the cycle time and costs for all future releases.
So why do we behave as if it's not true? Why do supposedly smart and cost-conscious businesspeople keep making dumb and expensive decisions?
One reason is that managers often view the production of software code in incremental amounts that must be written by a certain date, and so they believe that if you spread the task across more people, it will take less time. It's time the managers realize that, as these studies show, this view is not based on reality.