标签：#technicaldebt

You said you'd remove that flag after launch. You lied. It's been six months and the flag is still in appsettings.json , the if statement is still in your controller, and nobody remembers which state is "on." This is how codebases turn into haunted houses. Why Cleanup Matters Dead feature flags are technical debt with teeth . They add branches to your code that nobody tests. They confuse new developers who don't know the history. They inflate configuration files and make deployments harder to reason about. And they compound. Every flag you don't clean up makes the next cleanup harder because the cognitive load of understanding the system keeps increasing. The cost of removing a flag is lowest immediately after the feature ships, while everyone still remembers what the thing does. Six months later? Good luck. Track Every Flag You can't clean up what you can't find. Maintain a registry of every active feature flag with: Name Purpose Owner Date created Expected removal date This can be a spreadsheet, an issue tracker, internal documentation, or a dedicated feature flag management system. The format doesn't matter nearly as much as the habit. When you add a flag, add it to the registry. When you remove a flag, remove it from the registry. If your registry contains flags with no owner or no removal date, congratulations: you've found your next cleanup project. Set Expiry Dates Every flag should have a planned removal date when it's created. For example: Release toggles: Remove shortly after the feature ships. Two weeks is a reasonable default. Experiment toggles: Remove when the experiment concludes. Ops toggles: May be permanent by design. Permission toggles: May also be permanent, but document that explicitly. If a flag has been alive longer than its planned expiry and nobody deliberately extended it, it's already a zombie. Treat it accordingly. Make Cleanup Part of the Process Flag cleanup doesn't happen unless someone owns it. Add a cleanup step to your feature compl

Two posts ago I said I'd shipped code I never read. It's easy to write that as a general observation about the industry. It's less comfortable to go open your own repo and count. So I did. Here's what I found, and what I've actually done about it. The repo It's a desktop app I built for my own company. Roughly fourteen thousand lines of Python, a Tkinter UI, invoicing and documents and reports, the kind of internal tool nobody else will ever see. I had never written Python before I started it. I built it anyway, with a lot of AI help, learning as I went. That combination - no prior experience, heavy AI assistance, a real deadline because the business actually needed the thing - is basically a diff debt factory. I wasn't cutting corners on purpose. I just didn't have the knowledge to evaluate half of what I was merging, and it worked, so I moved on. What I actually found The clearest example took me months to notice. Five different parts of the app generate PDFs. Quotes, proformas, reports, petitions, heat treatment certificates. Every one of them was failing, in different ways, at different times, and I kept fixing them individually. Different error, different module, different patch. The actual cause was one thing: LibreOffice wasn't installed on the machine. Every one of those modules quietly depended on it to do the document conversion. Not one of them said so anywhere. I'd merged that dependency five separate times without ever registering that I'd taken it on. That's diff debt in its purest form. The code wasn't messy. It wasn't badly written. It just made an assumption I'd never read, and I paid interest on it five times over before I understood the principal. There were smaller ones too. A path handling bug that only showed up because my Windows username has a Turkish character in it - the code assumed ASCII and nobody, including me, had thought about it. Two Python versions installed side by side, quietly fighting. A stray quotation mark in my system PATH th

Every organisation that has run a significant software system for more than a few years has felt a version of the same thing: a change that should have taken days takes months, nobody can quite explain why, and the explanation that eventually gets offered — the domain is complex, the requirements changed, the previous team was careless — is almost never checked against an alternative approach for the software architecture or alternative framework choices, because the alternative was never built. There is no possible comparison to determine the solution chosen is a good one and there is no benchmark to measure "fit for purpose." This is the unfalsifiability problem, and it is worth stating plainly before anything else in this piece, because it is the reason the cost described below is so rarely traced back to its actual cause. Every system is built once. There is no version of your platform built the other way, running alongside it, that anyone can compare it to. So when a system works, the approach that produced it gets read as validated. When a system becomes expensive to change, the cost gets attributed to anything except the structural decision that caused it — because that decision was made years ago, by people who may have moved on, and there is no control group to prove that the structure was the variable that mattered. That absence of a control group is not a minor academic point. It is the reason a specific, avoidable pattern of cost has been able to spread through the industry for decades, get taught in courses, get validated in interviews, and still never be clearly named as a mistake. This article is an attempt to name it — and to offer something more useful than a diagnosis: a way to check, this week, whether it applies to you. The Villain: Process Over Product Ask almost any team building a significant piece of software what the goal of the project is, and the honest answer, more often than anyone would like to admit, is not "build the best-fitting prod