There’s a book that’s grown a cult-like following over the past couple of years that you may be familiar with called The Life-Changing Magic of Tidying Up. It probably belongs in its own genre somewhere between self-help and homemaking.
At its surface, Marie Kondo’s bestseller is about how you organize and declutter your home. But, she also suggests doing so can change your mental behavior. It can make you calmer. It can put you at peace. It can make you happier. And at least a few million other readers believe it can. I do too.
That’s because I’ve experienced this first-hand with a different kind of space—DoneDone’s codebase. For over eight years, we’ve been tidying it up as we go. The priority we’ve given to simply making the code better over time is the main reason I still really love working on the product.
The lifecycle of most codebases tends toward eventual rot. Some codebases get there really quickly. Others get there gradually. But, they all eventually get there. For some reason, the pull of feature enhancements, time constraints, developer fatigue, and business priorities always push code toward its own death. When tidying up code isn’t made a top priority, this will always be its general trajectory.
But, selling the concept of “cleaning up” with no measurable or immediate gain is futile. Why devote two weeks of developer-time to something that doesn’t give anyone but developers a boon? Even further, how does anyone know that the clean-up was worth it when you can’t really measure it?
These questions end up becoming rhetorical. Hence, devoting time to just tidying up rarely gets any widespread support within a business.
I wish I could write up a report that tell us DoneDone has been more successful because we took the time to straighten out its strewn permissions layer two years ago. Or, during the release of our new @mentions feature, we took time to DRY up and reduce some long-standing service methods. Or, any of the countless other micro-refactorings we’ve done both on the server and client-side to keep the code fresh. But, I don’t have any metrics. And to be honest, there are probably clean-ups we’ve done that would take years to justify from a time-savings standpoint.
What I can say for sure is this: Giving developers time to consistently better their own codebase keeps developers passionate about working on that codebase for the long run. If it means pushing out a feature release an extra few days, it is almost unequivocally worth it. Because, in the end, the benefit of enjoying the space you work in every day needs no metric.
