Growing up I moved quite a bit. Pretty much every 2-4 years until after I graduated college and got married. This meant my family and I were always cleaning out things and getting rid of anything that wasn’t used or useful so it didn’t need to be packed up and dragged to the next place and then unpacked again. I distinctly remember a very heavy set of almost unused Encyclopedia Britannica that didn’t make the cut one move because they had sat in a bookcase for two years untouched.
Moving a lot is good training for creating lean, optimized software
This experience ended up being good training for creating lean, lightweight, optimized software, which is the way, due to technology constraints, you used to have build it, especially when doing games, mobile, or embedded systems. There was no adding more memory, including a large dependency that you only partly need, or adding another node to a cluster. Sony was not going to add more memory, processing speed, or storage because you failed to make efficient choices creating your Playstation title.
Now storage is cheap, compute is scalable, SaaS tools are infinite, and everyone saves anything and everything thinking that it is super valuable. I have to think that if all the accumulated digital cruft and useless processes on the internet were dumped there would be no reason to create new datacenters. Don’t even get me started on how much crappy data organizations collect and store thinking it is worth its weight in gold. The two flavors I've been thinking about lately are software cruft and organizational cruft.
Onboarding a new developer surfaces “just in case” dependencies
These both came into focus while onboarding a new developer. When looking at the code the developer found abandoned code paths, "just in case" external dependencies, forgotten feature flags that were never cleaned up, obscure configuration toggles, entire repos that are no longer used, tests so out of date if run they corrupt the UAT database, and jobs created that were never run. Then when searching, they found Confluence documents that date back to the early 2000’s for software and hardware the project has not supported for over decades. Unlike my family moving all around the country there is no one forcing things to be cleaned up and moved, no landlord telling you you need to have all of your stuff out and the place cleaned by the 1st or you don’t get your deposit back.
The carrying cost of digital cruft
So what right? This isn’t costing us much if anything? Having a OneDrive folder tree with four "final_v2_FINAL" versions, 400 stale JIRA tickets, HubSpot lists nobody remembers building, and Confluence pages dating back 20 years. But this cruft isn’t neutral, there is a carrying cost even when it is untouched: search results get noisier, onboarding new people takes longer ("which of these docs is current?"), decisions get made on stale data because nobody archived the old version. And unlike a messy garage or an overdue library book, there's no quick feedback loop nagging you to fix it, no late fee, no fine, no landlord. The cost is real but it's diffuse and delayed, which is exactly the kind of cost humans and organizations are bad at acting on. Crufty software has bloat, an old CVE nobody patched, confusing patterns, and if it is confusing for humans, a confused knowledge base makes a confused AI assistant. If you use them, AI tools are trained/grounded on your company's docs and tickets are now ingesting all that cruft. Cruft just slows humans down or causes confusion, now it will actively misinform your AI tools.
I fully admit to hoarding my share of digital cruft. The iPhone apps I used to ship have a codebase I haven't opened in many years, and I genuinely don't know what's still load-bearing in there versus what's dead weight I was too lazy to rip out at the time. Feature flags for A/B tests that ended two years ago. A third-party SDK I added for one screen that got cut. I told myself I'd "clean it up before the next update when I had the time." There was no next update.
There’s no convenient time to clean-up digital cruft
The lesson I keep relearning is that cruft doesn't wait for a convenient time to get cleaned up, and if you don't build the habit of doing it as you go, you end up with a codebase you (or others) are afraid to touch instead of one that can be iterated on.
But I’m not the friggen maid, so who should clean this mess up? More free advice from the guy that follows some of his own advice.
- Treat digital storage like you had a moving truck with limited space, even when you don't. Almost everything can be archived and then deleted later.
- Schedule cruft removal like you'd schedule a move. Assign someone (ideally someone who has both expertise and authority) put an actual date on it, don't wait for pain. This applies to codebases, JIRA, Confluence, AWS, etc…
- Stale becomes dangerous faster with AI in the loop. Audit what your tools are actually reading. I have a feeling this might become an ISO requirement someday.
- Delete-by-default over keep-by-default for tickets/docs past a certain age. Again, almost everything can be archived.
Everyone still has a digital Britannica set sitting in a bookcase nobody's opened since wikipedia became a thing. But at least a landlord eventually shows up. Nobody's coming to evict you from your JIRA backlog with four hundred dead tickets, so it just sits there, gathering weight nobody's forcing you to feel. Maybe I'm just a neat freak overinflating the issue. Before you judge, go search your own company's Confluence pages and tell me I'm wrong.
