Economics of Software
Especially as engineers it can be easy to consider the success of software through a lens purely of technical excellence - which whilst no doubt an important factor in the success of any project, 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 help 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 an economic truth that we can explore further.
Barry Boehm published Software Engineering Economics 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.
It revolves around this simple formula:
Here, is measured in person-months, size in thousands of lines of code, 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 comes into effect. It's always greater than 1, typically ranging from 1.05 to 1.20. It captures that doubling the size of a project more than doubles the effort required. Each additional line of code adds its own complexity - potentially interacting with every existing line, creating a combinatorial effect of interactions.
Calculating an accurate exponent here is something the book goes into further but you don’t need to necessarily use the formulae to takeaway the lessons here. Instead, seeing software through an economic lens can help in the pursuit of creating systems that remain on track and successful.
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
The Finding: The productivity gap between great and average developers isn't 2x or 3x - it can be 10x or more.
We’ve all heard the jokes about 10x developers, but memes aside, COCOMO demonstrates that individual capability is a major cost driver especially over the long term. A few exceptional developers outperform small teams of average ones, this doesn’t just refer to technical expertise, but also team culture, domain expertise, and tooling.
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 those 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, who famously said “adding manpower to a late software project makes it later”. Communication overhead grows, tasks aren’t constantly divisible (another reason why exceptional devs beat average teams), and of course ramp up time. These all grow 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, have projects deployed and tested in real environments using effective CI/CD. 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 do-it-all “Swiss Army Knife” library which adds more complexity and overhead (remember this all feeds into effort). 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.