In my post on developing in a monorepo and splitting it up again for distribution, I referenced the Field Atlas entry “Software is a cost, not an asset“. Dr. Samek made a comment on that entry, which I will repeat here:
I’m so glad to see this point of view. For years we’ve been told that we are in an “embedded software crisis”, and hordes of developers will be needed to create ever more embedded software. But in fact, we might have too much of (poor quality) code and don’t know how to get rid of it. This issue was the subject of my old blog post “Embedded Software Crisis or Embedded Software Glut?”
To summarize Dr. Samek’s point in that post:
Adding code is easy. Removing dead code (without breaking the actually used parts of the code) is hard. But without the mechanisms for dropping the old baggage, we face a real Software Crisis.
I recalled these points while writing the monorepo post, and I realized that I had overlooked this method of reducing the cost of managing my software inventory: eliminating dead weight. I am facing a “software glut”, and a major step toward improving that is getting rid of as much unnecessary code as possible. That this did not even cross my mind ties into an article we reviewed in the Reading Club: Adding is Favoured Over Subtracting in Problem Solving. I was focused entirely on adding new capabilities rather than subtracting unnecessary elements from our software inventory.
As a first step in that effort, I’ve done some (pre-)spring cleaning. Over two hours, I reduced the number of active repositories by ~40%. Currently, 45 of the remaining repositories will be merged into the monorepo.
- Anything I never expected to touch again was deleted, like:
- Old client projects
- Failed and aborted internal projects
- Unmodified forks
- Anything that needed to be kept for historical reasons was archived:
- Public repositories that are referenced in website articles
- Public/private repositories that are referenced in the history of active projects
- Public repositories that might have users (based on fork/watch counts)
A common concern when deleting old code is that “it might be useful again in the future”. Of course, deleted code within a repository is never really lost – it’s kept in the history of your revision control system. But if you’re deleting repositories altogether, you can ease your mind by keeping a copy around:
- Create a “cold storage” repository and add deleted code to that repository.
- Checkout the repositories into a “cold storage” folder, preserving their history locally.
- If you ever need to recreate the repository, you can re-push and restore the same commit hashes.
Really, this is just a security blanket. It has been many years since I’ve needed to comb through the archives to find a particular piece of code. I don’t expect the new additions will change that fact.
“it might be useful again in the future” No, no it won’t. Even if it could be useful, it was written in a context (developer’s experience level, project requirements, planetary alignments, etc.) that doesn’t exist any more. It could be useful to see how the problem was previously solved but would probably be better off with a refactor at a minimum and a complete redesign/rewrite to fit the current context. The problem description and solution are the most valuable assets of old code, not the implementation.