Every program review I've sat in asks the same question: what are you adding? New capability, new features, new lines of code. In my capacity of software delivery in the government, I never once was asked what I killed.
That's the whole problem in one sentence. We measure what we build and we ignore what we refuse to retire, so the old never dies. It just accumulates.
BLUF: The Department of War (DoW) rewards addition and punishes subtraction. Every incentive points at fielding something new; nothing points at sunsetting something old. So legacy piles up as cost, as attack surface, and as a drag on everything built on top of it. The fix is to make deprecation a measured, funded, promotable outcome, the same way we treat delivery. Count what gets retired, pay for it, and reward the people who do it.
We only count additions
A program manager who fields a new system gets a budget line, a ribbon, and a bullet on the next evaluation. A program manager who turns off a twenty-year-old system that three offices quietly still depend on gets a risk memo and a bad afternoon. The incentive runs one direction, and the result is exactly what you'd predict.
The Government Accountability Office (GAO) found that about 80 percent of the federal government's roughly $90 billion annual information technology budget goes to operating and maintaining what already exists, not to building anything new. Multiple systems it examined were over 50 years old.[1] That is the compounding cost of a system that only ever adds.
And it isn't only money. Every legacy system we never turned off is attack surface we still defend, a dependency something newer is bolted onto, and a reason the next change takes longer than it should.[2] Unretired code is a standing tax on everything that comes after it.
A healthy unit kills old code.
Deprecation is a capability, not a chore
In any serious software organization, removing code is a first-class act of engineering. It shrinks the attack surface, cuts maintenance load, and makes the system easier to reason about.[3] The DoW treats it as janitorial work nobody is assigned and nobody is credited for.
Flip that. Make retirement something you measure and reward:
- Count it. Track code-in versus code-out: the ratio of new code and systems merged against old code and systems retired. A unit that only ever adds is running up debt, and now the number says so out loud.
- Fund it. I've argued elsewhere that the planning, programming, budgeting and execution (PPBE) process should score technical debt retired as a funded outcome, right beside capability delivered. You get budget for what you shut down, not only for what you stand up.
- Reward it. "I sunset three redundant systems and cut our operations and maintenance (O&M) bill by a quarter" should be a career-making bullet, not a footnote. Promotion boards should see a retirement the way they see a fielding.
- Force it. Put sunset clauses on systems, authorities, and pilots. They expire on a date and renew only on demonstrated use, so the default is death and survival is what you have to justify.
A retired cavalry officer could write a perfectly rational contract for horseshoes. The contracting was sound; the horseshoes were combat-irrelevant. We are still writing beautiful contracts for horseshoes, and calling the pile of them a portfolio.
The objections, answered
"You'll reward people for ripping out things that still work." Code-out only counts when the capability is genuinely gone or replaced, verified the same way a fielding is verified. Breaking a live mission thread shows up as a failure, not a retirement. You measure the outcome, not the act of deleting.[4]
"Some old systems have to stay." Of course. The point isn't zero legacy, it's a true accounting. A system that must persist carries a justification and a renewal date. What ends is the free pass that lets it live forever because no one was ever asked about it.
"This is just efficiency drum-beating." It's a security argument first. Every system you don't retire is one you still have to patch, defend, and reason about. Then of course that cost adds up in three columns: technical debt, security surface area, and the monetary costs to deal with it.[5] Deprecation is how you shrink the thing the adversary gets to aim at, decrease taxpayer burden, and simplify how new features get added.
The fix
Make subtraction a measured outcome. Report code-in/code-out at every portfolio review, score retired technical debt in PPBE as its own funded line, put a deprecation win on the evaluation next to a delivery, and attach sunset dates to systems and authorities so the default is retirement. None of this needs a new law. It needs leaders to start asking the second question, the one no review asks today: what did you kill?
What you can do Monday
- Unit commanders: At your next review, ask every program what it retired this quarter, not just what it shipped. Watch how long the silence lasts.
- PEOs / PAEs: Publish a code-in/code-out ratio for your portfolio and set a target for next year. Name one system you will sunset.
- Contracting officers: Write sunset dates and disposition plans into new awards, so retirement is a deliverable, not an afterthought.
- Service personnel offices: Add deprecation and O&M reduction to evaluation and promotion guidance as recognized achievements.
- DIU and the service innovation organizations: Report transitions with their retirement side too: what did the new capability replace, and did the old one actually get turned off?
- OSD: Direct that technical debt retired be scored in PPBE reviews, and attach sunset clauses to new systems and authorities by default.
- Congress: No new authority needed. Ask for one number in IT and acquisition reporting, operations and maintenance spending on legacy systems, retired year over year, and watch where it doesn't move.
Works Cited
2 Mace, Nancy. 2023. Mace: Aging Federal IT Systems are Vulnerable to Cyberattacks. May 10.
The conversation happens on LinkedIn — come argue with me there.