Over 15,000 and still counting. That’s how many lines of code we removed from the Tribune codebase in June of 2015. That’s about 3% of the codebase, which remains over 455,000 lines strong, according to a Sublime Text regex search.
How did we get here? Our team works in two-week sprints, and we sometimes give our sprints themes, which means all three of us work on tasks focused around a single goal, like performance. We’d had deletion of legacy code hanging around on our list for awhile. The Tribune has been around for over five years now, so there was quite a bit of code that the project had evolved beyond. We have code to be deleted detailed in Github issues and Basecamp lists. Some of this code has been a part of the site since as early as October 2009!
When you tell non-programmer colleagues that you want to spend a few weeks focusing on deleting code and lessening your technical debt, be prepared for a blank look. Then you’ll have to translate “code deletion” and “less technical debt” into an explanation of why it’s important to you (and to them, and the rest of the organization) that you delete that code.
I like to use the analogy of a house; if your rooms are cluttered with unused items, it’ll take you a lot longer to navigate through and get things done. If you have a nice clean house, however, you’ll be able to, for example, easily find your way to the kitchen and cook up a delicious dinner. Same with a codebase. If there’s unused code hanging around, it’ll take you longer to wade through it to see what it’s really doing and add a new feature or improve the existing ones. But when the codebase is clean and shiny, the new feature is easier to add in and can be built faster.
So recently, after explaining why cleaning up legacy code is beneficial to everyone within earshot of our corner of the newsroom, and reminding everyone multiple times that’s what we’d be focusing on for our sprint, we finally got to roll up our sleeves and get down to the business of deletion.
This summer was the perfect time for us to clean up the codebase, too, before our newest team member, Liam Andrew, joined us. This way, Liam wasn’t distracted by unused code, which eased his period of orientation with the codebase. We’re also gearing up for a few big projects on the horizon, so this helps us get ready to attack those. Our codebase feels fresh and clean now; although it’s only about three percent, it feels like more. Immersing ourselves in code deletion has also been a positive because it’s made us better programmers. When you’ve been in the weeds deleting unused code, it makes you approach adding new code with a more complex perspective and refactor code as you work.
Much of the code that we deleted was replaced with something else that provided a similar, but improved, functionality. For example, we removed the code powering our previous donation page when we went live with our new donations app where people can become members and support our work. We also removed our homegrown Twitter app taking up a large amount of database tables that were powering Twitter widgets on our site, and replaced them with the widgets provided by Twitter, removing the burden on our database and codebase and placing it onto theirs. In addition, we removed the paywall that we had been housing inside our code for our premium Texas Weekly product and replaced it with a third-party paywall, Tinypass.
Some things we archived and then deleted the code powering them. From this process of deletion, we’ve come to appreciate more deeply how important it is to think through the process for sunsetting a project once it’s no longer relevant. This is especially important for news organizations where most stories are at least somewhat time-sensitive. Otherwise, projects will hang around forever and ever and ever and related code will break. Sunset plans allow you to create a pristine archive of your organization’s work, and they’ll ensure old projects don’t keep you reliant on requirements and legacy code that could hold you back.
When you’re removing code from a large project, especially code that was written by a previous developer, it can be scary to delete a significant number of lines. What if you forget to delete something related and leave behind orphaned code? Most frighteningly, what if you miss something dependent on the code you’re deleting and break parts of your site?
Our test suite gave us some comfort when it came to removing this code. So did deploying and testing out the code in our staging environment, which closely mimics our production site. We also followed our policy of always having another team member comb through our code changes. That got-your-back help of having another pair of eyes on your work can be integral to catching all the details.
We’ve also stepped up our documentation game. We’d already started fattening up our internal wikipedia prior to all these deletions, but the deletions definitely kept the momentum going. I think of looking at legacy code like an archeological dig; the more of the bones and tools you have, the better you can understand what you’re looking at. And if you understand how code was used, you’ll know what you can safely remove when that code’s no longer needed.
Have you recently deleted some code from your organization’s codebase, or another project you’re working on? Do you have some code you’ve been meaning to remove but haven’t found the time and space to get around to it yet? We’d love to hear the story of your deletions, any challenges you came across, and how it feels now if you’ve already deleted the code and lessened your technical debt!