Why Code Maintenance Is Harder Than Anyone Admits

Robby Russell, creator of Oh My Zsh and CEO of Planet Argon, has spent two decades helping companies untangle their codebases. His consultancy specializes in the unglamorous work most developers know intimately but rarely discuss openly: maintaining software that somebody else built, probably years ago, under constraints you'll never fully understand.

In a recent freeCodeCamp podcast, Russell articulated something that rings true for anyone who's ever inherited a messy repository: "Most of our careers as developers are spent living inside someone else's decisions."

That includes your own past decisions, by the way. Russell points out that you're not even the same person you were six months ago—literally, if you believe the cellular regeneration timeline—so revisiting your old code often feels like archaeological work.

The 99% Problem

When asked what proportion of developer time goes to maintenance versus greenfield projects, Russell didn't hesitate: "I would be shocked if it wasn't 99, several nines of percentage."

That number might sound pessimistic until you consider what counts as maintenance. Adding a button to an existing page? Maintenance—you're working within existing constraints. Building a new feature in an established codebase? Still maintenance—the architecture decisions were made years ago. Even "new" work usually means appending complexity to what already exists, not starting fresh.

Some organizations try to carve out explicit maintenance time—20% for technical debt, 80% for features—but the boundary blurs quickly. You can't add that dropdown without first understanding why the form validation works the way it does. You can't fix that bug without tracing through decisions made by developers who left the company three years ago.

The Repository Problem

Russell sees a pattern when companies bring him in: 80 repositories, but nobody's touched 60 of them in five years. Are they still deployed? Are they dependencies pulled in as Git submodules? Are they forks of third-party packages someone patched while waiting for an upstream fix that never came?

"I don't think we're always really good at archiving those things when they're no longer being used or when that person leaves," Russell notes.

The organizational knowledge problem compounds itself. A developer forks a library to fix a critical bug, intending it as a temporary measure. Years pass. That developer moves on. The fork stays in the dependency list. New developers see it, don't know why it exists, don't know if removing it would break production. The safest move is to leave it alone.

Safety through inaction becomes the default.

When Rewrites Seem Appealing

Russell has seen the rewrite impulse play out dozens of times. A company adopts a hot new framework. Early adopters build something functional. The product finds market fit. The company hires more developers. Those developers aren't necessarily early adopters themselves—they're skilled professionals who can work with any stack.

Eventually, someone asks: "Wouldn't it be easier to rebuild this with [current hot technology]?" The old codebase feels tangled. There are workarounds nobody remembers implementing. The framework feels dated. A rewrite sounds clean, rational, resume-enhancing.

But Russell argues that rewrites often just "forget what you've already learned." That tangled code accumulated wisdom—edge cases you didn't anticipate, bugs you fixed at 2 AM, customer requirements that seemed bizarre until you understood the business context.

The gate analogy Russell uses is telling: he has a loose screw on his side gate. Does he fix the screw, replace the board, or rebuild the entire gate? In software, teams frequently choose "rebuild the gate" when "tighten the screw" would work fine. The problem is that software feels infinitely malleable, so the cost of rebuilding seems lower than it actually is.

The Tacit Knowledge Trap

When a key developer leaves, they take institutional memory with them. Why was this endpoint designed this way? Why does this validation happen client-side instead of server-side? What business requirement justified this architectural choice?

Without that context, new developers face two bad options: spend weeks doing forensic analysis of the codebase, or make changes based on incomplete understanding and hope nothing breaks.

Russell's consultancy exists largely to help companies navigate exactly this situation—not by magically recovering lost knowledge, but by helping teams build systems that make the codebase more comprehensible to people who weren't there when decisions were made.

What This Means for Security

From a security perspective, this maintenance reality creates significant risk. Unmaintained code doesn't just accumulate technical debt—it accumulates vulnerabilities. Those 60 forgotten repositories? Some of them are probably still running in production somewhere, pulling in dependencies that haven't been updated in years.

The rewrite temptation becomes particularly dangerous when security debt motivates it. Yes, the old authentication system uses deprecated libraries. But does the team fully understand what it does? Have they documented every edge case? Do they know why certain validation rules exist?

A security-motivated rewrite that loses institutional knowledge can introduce more vulnerabilities than it fixes. The old system might be clunky, but at least its failure modes were known.

The Maintenance Mindset

Russell runs a podcast called Maintainable, and his entire professional focus centers on this unsexy reality: most software work is maintenance work. Accepting that doesn't mean resignation. It means building systems and cultures that make maintenance sustainable.

That might mean better documentation, but documentation alone doesn't solve the problem. It means architectural choices that make intent clear. It means code review practices that transfer knowledge. It means resisting the siren song of the rewrite when incremental improvement would work.

It means understanding that "I would have done it differently" is a copout. The question isn't what you would have done in an ideal world. It's what you can do with the constraints you actually have, the code that's actually running, the knowledge that's actually available.

Because that's the job. That's what the 99% looks like.

Rachel "Rach" Kovacs is Buzzrag's cybersecurity and privacy correspondent.