ryuya.dev
Pencil sketch of a conveyor belt buried under a heap of junk, with one small box coming out at the end

Maximize Business Value per Line of Code

Thanks to AI, your team is merging twice as many PRs as it did last year. Tickets fly across the board into Done. Plenty of teams can’t even file tickets fast enough anymore, so changes just get merged without one. But did what your users actually got double? Did the business numbers?

If they didn’t, you’re counting the wrong thing. Tickets closed, PRs merged, story points burned, lead time. Each one tells you how many things got done and when. That’s output, and output is a point. Outcomes build up after you ship, a little at a time, for as long as people keep using what you built. They aren’t a point. They’re an area that grows over time.

An engineer’s job isn’t to produce more output, or to go faster. It’s to get as much area as possible out of every line of code you have to keep.

Output is a point. Outcomes are an area.

The day you ship, your code is worth zero.

Value starts flowing only when people start using it, and it flows at some rate: revenue you kept, hours someone no longer spends, risk you avoided, projects that come to depend on you. Multiply that rate by how long the code stays useful and you get the area. Ship late, ship something nobody uses, or ship something that keeps falling over, and the area stays small no matter how busy the commit log looks.

Both shipped the same day. Only the used one has area. Two features released the same day. Each square is a day, darker when more people used it that day; the bars underneath are the same numbers as a weekly average. Bulk edit builds up area. Export was never used, so its area stays at zero. Illustrative numbers. Bulk edit feature used Apr May Jun Jul Aug Sep Mon Wed Fri 0 1k 2k 3k people / day release days used 135 of 138 total area 350k people-days quiet week busy week outage 500 3,100 Export feature never used 0 1k 2k 3k 0 of 138 0 people-days

ROI and productivity both have area in the numerator. Ship fast and have nobody use it, and the numerator stays at zero while the cost in the denominator keeps climbing. You didn’t buy value cheaply. You paid, in money and time, for a feature nobody uses.

Features and maintenance grow the same area

Work that actually grows the area does one of five things:

  1. Ship sooner. Move the start date up so value flows for longer.
  2. Deliver more value. Raise the value per unit of time. Solve the user’s problem more completely.
  3. Stop losing value now. Outages, broken flows, quiet bugs nobody reports. Plug the holes in the area.
  4. Don’t lose value later. End-of-life dependencies, forced upgrades, platforms you can’t get off. Keep future area from disappearing.
  5. Stay changeable. Keep the next change from getting expensive.

New features mostly pull levers 1 and 2. Maintenance and reliability work pull 3 through 5. It’s the same area. They just push on different sides of it.

Five ways to grow the same area Each lever moved on its own. The dashed outline is today's area (100); the coloured part is what that lever adds, the same +10% every time. Ink is business work, green is reliability and maintenance. ① ship sooner +10% ② raise the rate +10% ③ no holes now +10% ④ no loss later +10% ⑤ keep it changeable +10% 0 6 12 18 24 months

But whichever lever you pull, you’re left holding code.

Features are assets. Code is a liability.

Picture owning an apartment building. Add a floor and the rent roll grows. So do construction costs, finding tenants, repairs, tenant calls, move-outs, and property taxes. Leave the new units empty and the repairs and taxes still come due every year. Code works the same way. The features that reach users pay the rent. Every line you keep brings review, tests, migrations, and on-call, plus cognitive load on the next person who has to read it. If it’s open source, add issue triage and backward-compatibility promises. You pay all of it whether or not that line is earning anything.

Vacant floors still take 120 engineer-hours a month A code base drawn as a six-floor building, one floor per feature. Upkeep is review, tests, upgrades and on-call, in engineer-hours a month (160 h = one engineer). The two vacant floors have no users and still take 120 hours a month. Illustrative numbers. floor (feature) weekly users upkeep h / month 1F Checkout 48k 90 2F Legacy sync 0 vacant 75 3F Search 32k 60 4F Billing 21k 75 5F Export 0 vacant 45 6F Reports 9k 50 total 110k 395 ≈ 2.5 engineers vacant floors 0 120 ≈ 0.75 engineer

The more code you have, the bigger the share of your time that goes to keeping the lights on. Grow what you own without growing the team, and the capacity left for new value shrinks. If you never shrink what you maintain, the only way to keep moving forward is to keep hiring. And if AI takes over maintenance for less than people cost, now you’re maintaining the AI.

There’s only one way out. Maintain less.

Deleting code is the job

So deletion and cleanup aren’t chores for a slow week. They’re core engineering work. Cutting without losing value is the mark of a great engineer.

Remove the empty floors: 120 hours a month back to new work The same building before and after its two vacant floors are removed. Weekly users stay at 110k; upkeep drops from 395 to 275 engineer-hours a month, about 0.75 of an engineer back on new work. Hatched windows mark floors with no users. Checkout 90 Legacy sync 75 Search 60 Billing 75 Export 45 Reports 50 Checkout 90 Search 60 Billing 75 Reports 50 BEFORE upkeep h / month AFTER upkeep h / month −120 h / month 2 empty floors removed 110k weekly users 395 110k weekly users unchanged 275 −120 h / month ≈ 0.75 engineer

Features and settings nobody uses, flags left over from experiments that ended long ago, compatibility shims nothing calls anymore. That’s product debt. Like a vacant unit, it carries cost and produces no area. Delete it. The target is code with no area, not line count. Squeezing working code into unreadable one-liners misses the point. An abstraction that rules out a whole class of mistakes adds value even if it adds lines.

What’s left is often technical debt: code that still earns its keep but is hard to change safely. Don’t delete it. Fix it and consolidate it without breaking the area it produces today. The goal isn’t prettier code. It’s making the next area cheaper to build. Put it off and you pay anyway, with interest, usually in the middle of an outage or a forced migration.

In the AI factory, the first job is deletion

Even once you’ve built a software factory and a fleet of agents handles the building and the maintenance, humans still run the factory.

The dashboard shows today’s merged-PR count, same as every other day. Then one day there’s an outage the AI can’t fix, and for the first time you look inside the factory. It’s full of junk. It’s barely shipping.

What do you do?

You start deleting. You hunt down the code with no area, and for every line you keep, you ask what value it produces. You don’t have to wait for the factory to break down to start asking. Start with today’s diff.

AI makes it more tempting than ever to add code. Hold the line.

Maximize business value per line of code.