Less Is More

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.

The reality is that the amount of code to be written depends on who is writing it. No two programmers will create the same code to do the same thing. Code is an expression of the author's thought process based on his experience, understanding, and style; therefore it is unique to each individual. For example, one person might implement the same functionality in a fraction of the code that another writes, but he may write it in a form so abstract it would be difficult for others to maintain. Coding is a constant process of making trade-offs.

Furthermore, the greater the number of code components you have, the more integration you have to do, which increases the opportunity for rough edges. Also, the smaller the piece of the puzzle each person is looking at, the greater the chance for misunderstanding or crossed wires. Of course this tried-and-true axiom relates to this situation all too well: "Too many chefs spoil the stew."

From this standpoint, the fewer developers the better. In my opinion, two is the ideal. You get a check and balance and don't have a single point of failure. Of course there are some projects that lend themselves naturally to three developers, or even as many as five, based on how loosely coupled the components are. With clearly defined boundaries, integration is easier.

But the real point—which is hard to maintain focus on in a time when everyone is in a hurry for everything—is that less really is more. What does this mean?

• Don't substitute quantity for quality. Learn to question offers for more people, as tempting as it sounds. Push for better people instead.
• Look past the deadline. Think about how the decisions you make today will affect the future.
• Do the math. Is it really worth $1.8 million (an extra 151 man-months at $12K per month) to save twelve calendar days for the first release—then pay premium maintenance costs for the rest of the software life?

Maybe the hardest change of all is to resist the all-too-human urge to build an empire, believing that the more people you have, the more power you wield. Instead, look at each resource as a layer of complexity: The more you have, the more it costs—and, in the case of software, the less you get—and the worse it is.