If you’re not careful, entropy creeps its way into your code base. You take a shortcut or code something in a way that you know is sloppy and you say to yourself “I’ll come back to that later”, but later you’re faced with new feature requests or some other Imminent Disaster(tm) and you don’t go back and clean up the mess you made earlier. This is only natural in a code base and when the messes are few and far between, it is tolerable.
However, at some point the messes accumulate and you need to do something about it because the mess is preventing you from making forward progress in a reasonable manner. Entire books have been written about this situation such as “Working Effectively With Legacy Code” by Michael Feathers (see my review), “Refactoring: Improving the Design of Existing Code” by Martin Fowler and “Refactoring to Patterns” by Joshua Kerievsky. One could even consider “Domain-Driven Design: Tackling Complexity in the Heart of Software” by Eric Evans to be a book full of advice about how to avoid the accumulation of entropy in your code base. Still, sometimes you find yourself with too much entropy in your code base and it’s time to do something about it.
In this post, we’ll take a look at an open source project with a code base that is over 30 years old and has accumulated some “cruft” along the way. We’ll discuss various strategies for coping with the cruft and how to get rid of it in as safe a manner as possible. After all, we don’t want to introduce bugs while we clean up cruft.
Legalize Adulthood! 
