Economics of Software
Especially as engineers it can be easy to consider the success of software through the lens purely of technical excellence - which whilst no doubt an important factor in the success of any project it does not exist in a vacuum. Every technical decision owes consideration to the economic landscape it's being built in, and optimising decision making around this can actually enable technical excellence.
Some lessons are already ingrained in us. We’ve all heard the phrase “don’t reinvent the wheel”. On the surface, it’s obvious advice, but beneath it lies a subtle economic truth: if every project required building libraries from scratch, we’d have very little working software.
Barry Boehm published Software Engineering Economics a way back in 1981 (yes, before I was born), where he developed the COCOMO model, which demonstrates how software cost can be both systematic and quantitative - in doing so allowing for better technical decision making. At the heart of it is a simple formula:
Here, is measured in person-months, size in thousands of lines of code (KLOC), and represents a multiplier based on cost drivers — such as team capability, tools, schedule pressure, and complexity of the environment.
The exponent is where COCOMO's insight becomes apparent. It's always greater than 1, typically ranging from 1.05 to 1.20. It captures a fundamental truth, that doubling the size of a project more than doubles the effort required. Each additional line of code doesn't just add its own complexity - it potentially interacts with every existing line, creating a combinatorial explosion of interactions.
Seeing software through an economic scope can help us in the pursuit of creating systems that are more efficient. Now there are more lessons than I could ever condense from Boehm's book here but there are some key and universal lessons we should all walk away with as engineers - or just generally as architects of software.
1. Complexity Scales Exponentially, Not Linearly
The Finding: A 10,000 line system isn't 10x harder than 1,000 lines - it's 15-20x harder.
Every new line can interact with every existing line. This creates combinatorial explosion. A "small" feature added to a large system costs exponentially more than the same feature in isolation.
What this means for you: Before adding any code, ask "Can we solve this without adding complexity?" The best code is no code. The second best is deleted code.
2. Developer Productivity Varies by 10x (And It's the Only Thing That Matters)
The Finding: The productivity gap between great and average developers isn't 2x or 3x - it's 10x or more.
COCOMO shows that individual capability is a major cost driver. While exceptional developers often outperform small teams of average ones, productivity is also shaped by team culture, domain expertise, and tooling. AI tools further widen this gap — great developers wielding them become large multipliers.
What this means for you: Spend more time recruiting. Wait for the right person. Once you find exceptional people, build around their strengths. A month finding the right developer saves years of suboptimal output. In the AI era, the ability to architect systems matters even more than raw coding speed.
3. Requirements Bugs Cost 100x More to Fix in Production
The Finding: A bug caught in requirements costs £1. The same bug in production costs £100-£1,000.
This isn't a linear progression, it's exponential. Each phase multiplies the fix cost because you're not just fixing code, you're also unwinding assumptions built on faulty foundations.
What this means for you: Never start coding until you can explain requirements to someone else and have them repeat them accurately. An hour of clarity now saves weeks of debugging later.
4. You Can't Accelerate Schedules by Adding People
The Finding: Doubling resources reduces timeline by only 30%, not 50%.
COCOMO proves Brooks's Law mathematically: Time ∝ Effort^0.38. Communication overhead grows quadratically with team size. Nine women can't make a baby in one month.
What this means for you: When asked to deliver faster, always respond with trade-offs: "Half the time = half the features." Never accept arbitrary acceleration without corresponding scope reduction.
5. Integration Takes 40% of Your Effort
The Finding: Integration and testing consume 25-40% of total effort, growing with system size.
Components that work perfectly in isolation generally fail when combined. Interface assumptions clash and edge cases multiply.
What this means for you: Integrate continuously, not eventually. Budget at least 30% of your schedule for integration. If you haven't, you're already late.
6. "Don't Reinvent the Wheel"
The Finding: Reusing existing code requires 30-40% of the effort of writing from scratch. True reusability only pays off after three or more uses.
That advice we started with - "don't reinvent the wheel" - is only half the story. COCOMO reveals the hidden economics, adapting existing code to your needs takes significant effort. Sometimes you need a wheel, but the only available option is a bloated Swiss Army forklift. Most "reusable" components are over-engineered for future requirements that never ultimately materialise.
What this means for you: Follow the rule of three - only build for reuse when you can guarantee three uses. Otherwise, build exactly what you need.
Reality Check
Software development follows economic patterns whether we acknowledge them or not. COCOMO didn’t invent these principles, it simply revealed them through empirical study of thousands of projects.
Complexity grows faster than code size. Productivity varies dramatically. Late-stage bugs are ruinous. Integration effort is unavoidable. These aren’t opinions or methodologies, but the underlying economics of software.
You don’t get to choose whether software economics applies — it always does. What you can choose is whether to acknowledge it and make better-informed decisions, or ignore it and pay the literal price.