The Hidden Costs of Complexity: Why Small Iterations and Teams Matter in Software Development

The software development industry is facing alarming trends that are reminiscent of past mistakes, threatening to repeat them. As a consultant, I've witnessed firsthand how these issues manifest in various organizations. There's an old saying: those who forget the past are doomed to repeat it. As a consultant, I encounter many dysfunctions in various organizations, which often stem from a lack of understanding of fundamental development principles and the underlying reasons behind widely adopted practices.

The idea behind small, releasable iterations is not just about adaptability. It's also about managing complexity and avoiding the exponential costs associated with larger projects. In the early 1960s, a report by Sackman, Erickson, and Grant found that developers working on projects with 3,200 lines of code took over four times as long to produce those lines compared to developers on projects with 1,600 lines. This finding emphasizes how the complexity of larger codebases significantly impacts development time and productivity. Studies by Nanus and Farr, and Wienwurm, both at System Development Corporation (SDC) in the 1960s, found slightly more optimistic results:

**Total Effort = (Time to produce one line) * (lines in delivery) ^ 1.5**

Whether the exponent is 1.5 or 2, all studies show that larger deliveries take exponentially longer to develop. This is a key insight that many organizations fail to appreciate when they decide to bundle features into larger releases, believing it will be more efficient. In reality, the increased complexity leads to longer development times, more bugs, and higher overall costs.

Another point that often gets overlooked is team size. Recently, I worked on a project with three developers and eight others, for a total of eleven team members. Everyone had input, and we adjusted as each presented their point of view. This is becoming increasingly common, but it introduces significant challenges. The Scrum Guide used to refer to this dynamic as "pigs and chickens," referencing an old joke: The story goes that a pig and a chicken decide to open a restaurant. The chicken suggests they call it 'Ham and Eggs.' The pig thinks for a moment and says, 'No thanks. You'd only be involved, but I'd be committed.' In the context of Scrum, the 'pigs' are the team members who are fully committed to the project, while the 'chickens' are those who are merely involved and provide input without being fully accountable. This reference was eventually removed, but the effects of having more people involved in the development process remain. Joel Aron, a manager at IBM in Gaithersburg, Maryland, conducted research that aligned with the work at SDC. He found that developer productivity is inversely proportional to the number of communication channels. This is because more communication channels require increased time for coordination and alignment, leading to greater overhead and reduced individual productivity. If you hand a fixed, up-front definition to a single developer and do not interact with them, they might produce 10,000 lines of code a year. Add two or three people to the team—whether managers or developers—and that 10,000 decreases to 5,000. If the two or three are all developers, they might cooperatively write 20,000 lines, but individually, they will only produce 5,000 each.

This reduction in productivity is largely due to the increased communication overhead. Each additional person on a team adds more communication channels, which requires more time and effort to keep everyone aligned. The need to synchronize, discuss, and agree on various aspects of the project can significantly slow down progress. John Harr from Bell Telephone Labs continued this research with his own teams, focusing on team size. He concluded that when projects have 80 or more developers, the average lines of code per developer drops to 515. This stark decrease highlights how larger teams can become increasingly inefficient, as the coordination costs overwhelm the potential benefits of having more people.

If we take the numbers as written, what eighty developers can do on one combined project might be accomplished by four or eight if the work is divided into small, deliverable increments. This might be overly optimistic, but I've been on multi-year projects with over twenty developers that ultimately went nowhere. The failure of these projects wasn't due to a lack of skill or effort but rather the complexity introduced by too many people and too few manageable deliverables. Large teams often struggle with aligning everyone, maintaining a shared vision, and avoiding duplicated or conflicting work.

There are fundamental reasons why we avoid large, "big bang" deliveries beyond agility and flexibility—these are just added benefits that come along with small, iterative deliverables. By keeping iterations small, we reduce the risks associated with complexity, communication overhead, and misalignment. Smaller deliverables allow for quicker feedback loops, more accurate progress tracking, and an overall more sustainable pace of development. The historical research into development productivity provides a clear rationale for why these practices are so effective. Yet, without understanding the "why," many organizations inadvertently fall into the same traps that have plagued software projects for decades, such as overestimating the benefits of larger teams, failing to properly manage communication overhead, and ignoring the impact of increased complexity on productivity.

To truly benefit from Agile practices, organizations need to internalize the lessons from past research and understand that small iterations and small team sizes are not arbitrary guidelines—they are proven strategies for managing complexity and maximizing productivity. Without this understanding, the practices lose their effectiveness, and teams risk falling back into dysfunction. By appreciating the underlying reasons for these approaches, companies can make more informed decisions that foster both developer productivity and project success.