What You Inherit

There’s a moment every developer knows. You’re reading through a codebase, looking for the logic behind a decision that makes no sense, and you check the commit history to find out who to blame. Then you see your own name.

I went through that about two years ago on my own code. Had a good time with it — smiled every time I asked myself “who wrote this shit?” and then discover it was me. Kept me humble for the rest of that project.

Which is why, when I came back to a former employer as a contractor, I arrived with no stones to throw. I’m working on the first of four modernization projects — four aging applications that need to be brought forward. In the planning sessions for this first one, I sat across from the person who originally wrote it. We spent time trying to understand certain decisions in the code: why things were done the way they were, whether to keep them or refactor around them. He couldn’t tell me why they were made. I couldn’t tell him either.

I don’t blame him. When projects are piling up waiting to be started, there’s no time for maintenance, no time for the regular reviews and refactoring that would have kept things legible. Technical debt doesn’t accumulate because developers are careless. It accumulates because the queue never empties. The decisions that look strange now made sense in the moment, under the constraints of the moment, and then nobody came back.

The app itself is, charitably, showing its age. Three major versions behind in its language base, and the framework version it uses hit end of life before Jay Leno’s run on the Tonight Show did. The security team — a new addition since I was last here — is unhappy about it. The server admins, who are the same old cranky bastards they’ve always been, are equally unhappy about the two servers on life support keeping these four applications alive. It’s not Fortran, but it’s getting there.

Part of what’s interesting about coming back to this organization is watching which ideas have landed and which haven’t. When I was here the first time, I was pushing for containerization, proper version control, tests, regular refactoring. Some of that has made it. Teams that weren’t doing it then are doing it now. Some of it hasn’t caught up yet. We’re containerizing these four applications — which is progress, and I’ll take it — but a tightly-coupled monolith in a container is still a tightly-coupled monolith. The container might just clarify what else needs to change.

Halfway through the first phase, the original developer got pulled onto something else. That’s the other thing that hasn’t changed: the queue never empties. So I’m finishing it on my own. Which is a different experience than it would have been a few years ago — I have Claude available now in a way that genuinely functions like having someone to think out loud with. Not a replacement for the person who wrote the code and knows why. But something.

What I keep coming back to is that inheriting code is mostly a time problem, not a handoff problem. The original author’s context doesn’t survive years of inattention any better than yours does. The decisions lose their explanations. The workarounds become load-bearing. The TODOs are still there. Coming back to something is almost always harder than starting fresh — which is its own argument for the maintenance cycles that don’t happen when the queue never empties.

Four projects, each with its own archaeology. I’ll write about what I find.