The person who keeps it running

There is a particular kind of software that nobody writes about. It was finished before the current mobile era. Its authors have moved on, changed careers, in some cases retired. It has no roadmap, no product manager, and no conference talks. Every month it invoices tens of thousands of people correctly, and if it stopped, they would notice within the hour.

I maintain systems like that. Mostly Perl, mostly for internet providers, some of it older than the smartphone in the subscriber's hand.

Nobody chooses this on purpose

Developers tend to treat legacy code as a stage that ends: you inherit it, you migrate off it, you tell the story afterwards. That framing assumes a destination. For an operator with a working billing system and a subscriber base that grew around it, there often isn't one — not because migration is impossible, but because the business case for a rewrite is much weaker than engineers like to believe.

The system already encodes twenty years of decisions. Which day of the month a tariff switch takes effect. What happens to a promised payment when the subscriber pays half of it. How a service is suspended in a way that the support desk, the router, and the invoice all agree on. None of that is written down anywhere except in the code, and much of it was learned the expensive way, from customers who complained.

A rewrite does not inherit that knowledge. It re-learns it, in production, from the same customers.

The mindset the work actually requires

The technical part is not the difficult part. The difficult part is a stance you have to adopt and keep: assume the existing behaviour is intentional until proven otherwise.

Every strange branch you find is a candidate for two readings. Either someone wrote it badly, or something happened once and this is the scar. Early on you assume the first. After enough time you learn the second is more common than it has any right to be — and that the cost of guessing wrong is not a failed test, it is somebody's connection cut off on a Friday evening.

That leads to habits that look overcautious from the outside. Changing less than you could. Preferring the boring fix. Being suspicious of your own cleverness, especially at the moment it feels most justified. Treating "I don't understand why this is here" as a reason to stop rather than a licence to delete.

Why it matters more than it looks

An ISP's billing system is where the business actually lives. Not the website, not the app — the thing that knows who is a customer, what they owe, and whether their connection should be on right now. It is infrastructure in the literal sense: nobody thinks about it while it works.

Which is also why the work is invisible. There is no launch. The best possible outcome of a month's careful effort is that nothing happened and nobody noticed. You do not get credit for the outage that didn't occur.

I've come to think that is fine, and even part of the appeal. There is a satisfaction in being the person a provider calls when something that has run for two decades starts behaving oddly, and in the fact that after the call it goes back to running for another two decades. Not everything worth doing is new.

The other half of my week

The contrast with the rest of my work is sharp enough to be funny. The same week can contain a React Native release going through App Store review and a Perl script whose comments are older than the framework. One of those jobs rewards moving quickly. The other punishes it.

Doing both has made me better at each. Legacy work teaches you what a decade of unmaintained decisions actually feels like from the inside, and you carry that forward into the code you write today — knowing that someone will inherit it, and that they will have to guess at what you meant.