Knowing what not to fix

There’s a typo in the name of an app I shipped. It’s right there in the package identifier, a single wrong character, and every time I see it I wince. I am never going to fix it. Not “haven’t gotten around to it.” Never, on purpose.

Here’s why that isn’t laziness. A package name isn’t a label you can rename. To the app store it’s the app’s permanent identity, the primary key for the whole thing. Changing it doesn’t edit the typo; it publishes a brand-new app under a new identity and orphans the old one. The “fix” means shipping a second app, then convincing every existing user to find it, download it, and migrate across, losing whoever doesn’t make the trip. The typo costs me nothing but pride. The fix costs real users. So the typo stays, a small permanent scar, with a one-line note next to it so the next person knows it was a decision and not an oversight.

The most senior column says “don’t fix”

We talk about tech debt like it’s all owed to the same lender, like a responsible engineer eventually pays it all down. On a one-to-three person team, that’s a fantasy. Your scarcest resource isn’t compute or money, it’s the one engineer’s month. A debt list where every row says “fix” is just a list of everything you’ll feel guilty about. The useful version has a second column, and the bravest rows say “leave it.”

That column is the senior one. Anyone can file a ticket. Deciding, in writing, that a real and ugly problem is not worth solving is the harder call, because you have to own it later when someone discovers it and assumes you missed it.

The expensive ones you walk past

The typo is the dramatic example. Most of my “don’t fix” calls are quieter and look just as reckless on paper.

• The single shared database. Splitting the services apart would be cleaner. It’s also months of careful migration for a benefit nobody on the team can feel yet. Until the shared schema actually hurts, it stays.
• The boring deployment. Docker Compose on one box is not impressive. It is completely fine for the load we have. I’m not going to cosplay as a company with a thousand engineers and stand up Kubernetes to serve a few hundred users. The day I feel the pain, I’ll move. Not before.

Maturity in debt triage isn’t fixing the most things. It’s having the nerve to write “document the constraint and stop” next to the ones that aren’t worth your only engineer’s month.

How I actually decide

The test is small and almost embarrassing: who feels this, and when? If the honest answer is “nobody, until we’re ten times bigger,” it goes in the leave-it column with a sentence naming the trigger that would change my mind. If the answer is “a user, today,” it jumps the queue no matter how clean the surrounding code is.

That sentence matters more than the verdict. A constraint you wrote down on purpose is a boundary. A constraint you just never got to is a liability waiting to be found by someone who assumes you were careless.

So no, I’m not fixing the typo. I thought about it, I priced the scar against the only month I have, and the scar won. That’s not debt I’m ignoring. It’s debt I looked dead in the eye and chose to keep.