Clean the f… up! January 21, 2026

My new motto is, Clean the f… up!

The “f” is for files, of course.

By cleaning up, I mean not leaving obsolete, unused, temporary stuff lying around. A house is finished not when the walls are complete but when the scaffolding has been removed and the dirt has been swept up so people can live in it without constantly tripping over rubble. Similarly, software is finished not when the tests pass but when all temporary experiments, exploratory meanderings, and temporary workarounds for unfinished parts have been cleaned up – deleted, maybe archived, but in any case removed from the sight of the maintainer who will have to work with the results.

A refactoring is finished not when the new code is operational, but when the old code has been deleted. Not commented out! You are using a version control system, aren't you? If so, deleted code is not lost anyway. There is no point in unused code cluttering up your workspace.

I've heard people say we should hang on to old stuff because there is no harm in it, and “what if we need it again some time?” Well, let me show you some examples.

Just recently, I wanted to make a change to the monitoring setup at a customer project. The change went smoothly in the dev environment, but deployment failed in the production environment. This is a Kubernetes cluster, and applications are installed via Helm. The Helm charts are pulled from an internal registry. The step that failed was the login to this registry. An hour and conversations with 3 different people later, the problem was solved. One of the people I talked to had sent me down the wrong road by suggesting that the credentials we had configured were obsolete; we should authenticate with this other user instead. Actually, the solution was even simpler. You see, during a platform migration half a year ago, the systems had been wired up in such a way as to render the explicit login unnecessary. It had kept working for a time, but apparently now there had been a permission cleanup, and the login stopped working. Simply deleting the login step made the deployment work again.

Actually, the team knew about this. One of the people I talked to was an engineer on my team, and he gave me the hint that allowed me to fix the problem. Cleaning up the deployment process at the time of the migration half a year ago would have cost 5 minutes of engineering time. They had to change the very same file anyway. Doing it now cost about 2 hours and blocked other work. As I said, …

Clean the f… up!

Another thing I am currently working on is improving the performance and stability of the test suite. This project uses a whole lot of integration tests with a containerized database. The tests are based almost exclusively on a common set of test data in the form of a large (large!) SQL file. The file has gotten pretty big and unwieldy (did I mention it was large?), and if a test fails, finding the relevant input data is a major pain in the ass. It is also slower to load into the database than I would like. I'm pretty sure most of the data in the reference data SQL file is not actually used, but the team has a culture of keeping stuff around “in case it is needed again.” Due to this, we are now at a point where it is difficult to tell which parts are needed and which parts aren't. Keeping something like this manageable is much easier if you don't keep unused stuff lying around, so …

Clean the f… up!

A code base I know uses Hibernate ORM at the persistence layer. One of the entities exists twice in the code base. Both implementations read the same database table, but contain a different set of relations. One of them has been deprecated 2 years ago and sports a comment stating that it has evolved into a god class and should not be used; usages should be replaced by the other class. Can you guess in how many places this class is used versus the other one? Right.

Eliminating usage of the deprecated class is not trivial, I grant you that. The replacement is not a drop-in; you need to refactor any code that uses it, which is not a fun exercise. But you know what's worse than sticking with a badly designed class? Having to deal with a badly designed class plus another class for the same thing in the long term.

Clean the f… up!

One customer uses a vulnerability scanner to scan all containers running on the production Kubernetes cluster. One day two months ago, we got an alert for a dependency. The normal process after receiving such an alert is to update the dependency to a non-vulnerable version. In this particular case, the alert was for an indirect dependency, and there was no clear upgrade path because it was no longer actively maintained. Figuring out what to do took some time. In the end, I noticed that the dependency was only required by obsolete code (a part of the service that was no longer in use). The solution was to remove the dead code – and the dependency, of course. Again, figuring out which parts were really unused and which parts were still necessary was not trivial. It would have been much easier if this had been done at the time when the part of the service had been decommissioned by the people who were working on it. It took me much longer, plus we had vulnerable software in production for no good reason.

Clean the f… up!

Keeping obsolete, unused, temporary stuff around is not free! The cost may not be immediately obvious because leaving it there feels like being faster in the moment. But the cost (in terms of engineering effort) of cleaning up later is almost certainly higher than the cost of cleaning up right away. So do yourself – and your organization – a favour and clean the f… up!

Thank you.