42% of engineering time never touches a feature

Where does the other 42% go? Not into features. Stripe's developer survey clocked engineers at 17.3 of 41.1 weekly hours on maintenance — servicing old code, not shipping new value. Newer data says the share is holding or rising. And in a four-vendor route-to-market stack the headline number flatters you, because maintenance stops being code and becomes coordination across companies that do not share your backlog.

Where does the missing 42% actually go?

The figure comes from Stripe's 2018 report The Developer Coefficient, a survey of more than 1,000 developers and technology leaders. It found the average engineer worked 41.1 hours a week and spent 17.3 of them on maintenance — roughly 42% — split between technical debt and outright bad code. The report scaled that up to about $300 billion of global GDP lost to developers cleaning up rather than building. You can quarrel with the extrapolation. The per-developer split is harder to wave away.

Read the bottom two rows together. Before anyone joins a planning call, reviews a pull request, or waits on a test environment, a third of the week is already committed to code that shipped years ago. New features compete for whatever is left of the other 58%.

Has the number improved since 2018?

No, and if anything the framing has hardened. Cortex's 2024 State of Developer Productivity, drawing on more than 500 engineering organisations, put the share of time spent on maintenance at around 32%, with hands-on feature coding squeezed into a similar band. The same study reported that 69% of developers lose eight or more hours a week to inefficiencies — context switching, waiting, and hunting for information. Eight hours is a full working day, gone every week, before you count the maintenance itself. If you have read our note on how a feature spends 80% of its life waiting, this is the same disease measured from the developer's chair rather than the ticket's.

Why is maintenance worse across four vendors?

This is where the enterprise number diverges from the survey. Stripe and Cortex measured developers inside a single organisation. A large brewer's route-to-market estate is rarely a single organisation. Order capture is one vendor, stock another, loyalty a third, delivery a fourth — each with its own release train, its own on-call rota, and its own commercial incentive to define any given bug as someone else's problem.

In that world, maintenance stops being a code activity and becomes a coordination activity. A returnables discrepancy that would be a two-hour fix in one codebase turns into a three-week reconciliation across three vendors who each need the other two to move first. The engineering hours barely register. The calendar time and the meeting load are where the cost actually lives — the same coordination tax we pulled apart in the 300,000-hour meeting, and the same dynamic that keeps large IT programmes 45% over budget for roughly half the promised value.

Why doesn't more headcount fix it?

The instinct is to buy the 42% back with people: hire more engineers, or contract a bigger delivery partner, and let volume absorb the maintenance load. It rarely works, because the constraint is not how many hands you have. In a stitched-together estate the bottleneck is someone else's release train. You can staff your own side of an integration to the ceiling and still wait a fortnight because the stock vendor batches changes monthly and the delivery vendor freezes over quarter-end. Adding engineers to a coordination problem tends to add interfaces, not throughput — every new team is another party that has to be consulted, scheduled and signed off. It is why a maintenance backlog can grow while utilisation looks healthy, and why the honest lever is structural rather than a question of capacity. More people accelerate work that is genuinely code; they do very little for work that is genuinely negotiation.

What does the tax look like on one ticket?

A driver marks a delivery short by two cases. That single fact now has to be re-represented in the order record, the stock ledger, the returnables count, and the settlement feed: four schemas, four teams, four change windows. The code fix in any one of them is trivial. Agreeing on which vendor owns the corrected number, and scheduling four deployments that do not collide, is where the weeks disappear. Every one of those hours lands in the 42% bucket, and none of it produces anything a customer can see. Multiply that by every edge case in returnables, promotions and settlement, and the maintenance share is not a survey abstraction — it is most of the roadmap.

The direction out is unglamorous: collapse the coordination surface before you optimise the code. When order capture, stock, returnables and delivery publish to one event bus instead of negotiating across four contracts, a maintenance fix has one owner and one deployment, and the cross-vendor round-trip simply drops off the critical path. Engineers still maintain things; they just stop needing four calendars to do it.

The 42% will not fall to zero — some share of any engineer's week always belongs to what already exists. The question worth asking in 2026 is narrower and more answerable: how much of your maintenance is genuinely code, and how much is the overhead of asking four companies to agree on a number that should only ever have been written once? Shrink the second, and the first becomes a tractable engineering problem again.