Economics of software
Engineers tend to judge software purely on its technical merit. Fair enough, it matters enormously. It doesn't happen in a vacuum though. Every technical decision gets made inside some economic reality, and I'd say getting that reality right is quite 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", and on the surface it's obvious advice. I think there's an economic argument hiding underneath it though, and it's worth pulling out.
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, and that's what bends the cost curve: double the size of a project and you more than double 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 with the economics in mind and I think it gets a bit 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 does. A "small" feature dropped into a big system costs far more than the same feature built in isolation. The growth is super-linear rather than exponential, a power law rather than a runaway doubling, though in practice big systems punish you either way.
So before adding any code it's worth asking whether we can solve this without adding complexity. The best code is no code, and 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. Raw technical skill is only part of it too - team culture, domain knowledge and tooling all feed in.
Which suggests spending more time recruiting and keeping the right people, and being willing to 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 I'd say this matters even more, since 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 unwinding every assumption that was built on the faulty foundation, as well as fixing the code.
So I'd hold off on 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, I find it best to answer in trade-offs: "Half the time means half the features." I wouldn't accept an arbitrary acceleration without cutting the 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 have a habit of falling apart when you wire them together. Interface assumptions clash, edge cases multiply.
The fix, as far as I can tell, 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.
Which means the advice we opened with is only half the story. COCOMO shows that adapting someone else's code to your needs isn't free, and 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. I'd 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 any of these forces, it just makes them visible, so we can use them when building our own software. I don't think technical excellence and economic sense are rivals anyway, you want both.