---
title: Maximize Business Value per Line of Code
description: Shipping is a point in time. Business value is the area that builds up for as long as the code stays in use, and an engineer's job is to grow that area for every line they keep.
pubDate: 2026-09-21T12:00:00-07:00
tags:
- engineering
- productivity
- product
lang: en
translationKey: maximize-business-value-per-line
draft: false
heroImage: ../../assets/posts/maximize-business-value-per-line/hero.webp
heroImageDark: ../../assets/posts/maximize-business-value-per-line/hero-dark.webp
heroAlt: Pencil sketch of a conveyor belt buried under a heap of junk, with one small box coming out at the end
---
import ValueCalendar from '../../components/figures/value-per-line/ValueCalendar.astro';
import FiveLevers from '../../components/figures/value-per-line/FiveLevers.astro';
import UpkeepFloors from '../../components/figures/value-per-line/UpkeepFloors.astro';
import DemolishFloors from '../../components/figures/value-per-line/DemolishFloors.astro';
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.
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.
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.
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.
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.**