Economics of Software
Engineers tend to judge software purely on technical merit. Fair enough - it matters enormously. It doesn't happen in a vacuum though. Every technical decision is made inside an economic reality, and getting that reality right is often what lets the technical excellence happen at all.
Some of this is already baked into us. We've all heard "don't reinvent the wheel". On the surface it's obvious advice. Underneath it sits an economic truth worth digging into.
Barry Boehm published Software Engineering Economics back in 1981, where he laid out the COCOMO model. It showed that software cost can be measured systematically rather than guessed at, which in turn gives you a better basis for technical decisions.
The whole thing hangs off this formula:
Effort = a × (Size)^b × M
Effort is in person-months, size in thousands of lines of code, and M is a multiplier for cost drivers like team capability, tooling, schedule pressure, and how nasty the environment is.
The interesting bit is the exponent, b. It's always greater than 1, usually somewhere between 1.05 and 1.20. That's what makes the cost curve bend: doubling the size of a project more than doubles the effort. Each new line of code can interact with the lines already there, so the work grows faster than the codebase does.
Calculating an accurate exponent is something the book gets into properly, but you don't need the maths to take the lesson. Look at software through an economic lens and it gets easier to keep a project on the rails.
1. Complexity scales faster than linearly
A 10,000 line system isn't 10x harder than a 1,000 line one. With a typical exponent it's closer to 15x.
Every new line can touch every existing line, and the cost of those interactions piles up faster than the line count. A "small" feature dropped into a big system costs far more than the same feature built in isolation. The growth is super-linear, not exponential - it's a power law, not a runaway doubling - but the practical effect is the same. Big systems punish 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 gap between a great developer and an average one isn't 2x or 3x. It can be 10x or more.
We've all heard the 10x developer jokes. Memes aside, COCOMO treats individual capability as one of the biggest cost drivers, especially over the long haul. A handful of exceptional people will out-build a small team of average ones. This isn't only about raw technical skill - team culture, domain knowledge, and tooling all feed into it.
Spend more time recruiting and keeping the right people, then. Wait for the right person. Once you've found exceptional people, build around what they're good at. A month spent finding the right developer saves you years of mediocre output. In the AI era this matters even more: knowing how to architect and debug a system beats raw coding speed.
3. Bugs cost up to 100x more to fix in production
A bug caught in requirements costs £1. The same bug in production can cost £100-£1,000.
It's not a linear climb. Each phase multiplies the cost, because by then you're not just fixing code - you're unwinding every assumption built on the faulty foundation.
Don't start coding until you can explain the requirements to someone else and have them repeat them back accurately. An hour of clarity now saves you weeks of refactoring later.
4. You can't buy back a schedule by adding people
Doubling the team doesn't halve the timeline. You might shave 30% off if you're lucky.
This is Brooks's Law in action. Fred Brooks famously put it: "adding manpower to a late software project makes it later." Communication overhead grows, work doesn't split cleanly (another reason exceptional devs beat average teams), and new people need time to ramp up. Nine women can't make a baby in one month.
When someone asks you to deliver faster, answer in trade-offs: "Half the time means half the features." Never accept arbitrary acceleration without cutting scope to match.
5. Integration eats a quarter to a half of your effort
Integration and testing tend to swallow 25-40% of total effort, and the share grows with system size.
Components that behave perfectly on their own fall apart when you wire them together. Interface assumptions clash, edge cases breed.
The fix is to integrate continuously - keep the thing deployed and tested in a real environment with proper CI/CD. Budget a solid 30% of your schedule for integration. If you haven't, you're already late.
6. "Don't reinvent the wheel"
Reusing existing code takes roughly 30% of the effort of writing it fresh. Building something to be genuinely reusable only pays off after three or more uses.
That advice we opened with is only half the story. COCOMO shows that adapting someone else's code to your needs isn't free. Sometimes you need a wheel and the only thing on offer is a bloated, do-everything "Swiss Army Wheel" that drags in complexity, mental overhead, and dependencies you now have to maintain.
Plenty of "reusable" components are over-engineered for requirements that never arrive. Follow the rule of three: only build for reuse once you can see three real uses coming. Otherwise build exactly what you need.
Reality check
Whether we admit it or not, software decisions are shaped by economics. COCOMO didn't invent these forces - it just makes them visible, so we can use them when building our own software. Technical excellence and economic sense aren't rivals. You want both.