Restored using the Wayback machine from: https://www.developwithpurpose.com/digital-lumberjack/
When we had our development team blog, our content team would edit our posts. This one was very different before it went in to copy editing, I had embellished the lumberjack metaphor a lot more than this, and they cut it back.
Also, I took out the clickbait title.
In EntreLeadership, Dave talks about catching people doing something right. In the web development team, we like to recognize people publicly by handing out awards every month. Last month we introduced a new award: the Digital Lumberjack Award. The award is intended to recognize team members who have cut down digital trees that are no longer bearing fruit, and I was honored to be the first recipient.
Here's how I became a digital lumberjack:
1. Do a Controlled Burn to Prevent a Forest Fire
In forest management, there is a technique known as controlled burning. Parts of a forest are burned to clean out the underbrush and built up leaves to decrease the likelihood of a more serious fire. For a large web site, cleaning out the decaying or dead parts of the system can prevent more serious issues. Removing old pages, endpoints and other ways into your code reduces your overall attack surface. By cleaning out duplication, future refactorings also become easier.
One of our internal tools used to have several ways to get to the same information. There were several reports that were mostly identical, but each showed slightly different views of the same information. The application was written in the distant past, where "copy and paste" was a recognized design pattern, so there was a lot of duplication in the code. These reports used parts of our data model that we wanted to change, and since the code was repeated in multiple places, it made the job of changing the data model more difficult. The security model also varied between the reports. On certain reports, users could only see some information, whereas others exposed a lot of information.
By refactoring the common features of the reports into one component and centralizing the security, it allowed for us to show the right amount of information in all places as well as enabling easier future changes to the data model.
2. Leave a Well-Marked Trail
Parts of a large codebase can become like an unused path: obscured over time and obsolete. Methods that were once useful for a report are no longer called for. Pages advertising a one-time event in 2007 no longer have any meaning. Three database tables accompanied by 1,000 rows of data for an experiment in 2003 loom out there. All of this code and data rot can slow down your trek to where you really want to be.
Two years ago, I worked on some "find all places that do X and change it to do Y" changes. These were valuable changes, but each touched somewhere around 50 files. After exploring the codebase, I discovered only about 20 were actually still used. Especially since I spent a non-trivial amount of time tracking down actual uses, I wanted to be sure I was the last one who had to go down the dead-end paths. By removing the dead code, the next developer to work on those apps will have less exploring to do.
3. Make Room for New Growth
Every few years we make some big shifts in our code's direction. We replaced our original website--a couple of pages slapped together--with a rather primitive framework. Then, three years ago, daveramsey.com was completely redesigned with an MVC framework. We are fast approaching our next major shift in technology, but our codebase still contains elements of the past two stacks. As we make shifts to more modern frameworks and tools, maintaining the legacy systems becomes a burden. Working on them is less exciting, newer team members aren't as aware of how the older frameworks behave, and the code starts to rot.
What are your options? First, you can keep track of the use of that application, and as it falls into obscurity, cut it down and remove it when it is no longer used, or rewrite only the functionality that is still useful. Or you can rewrite these older systems right away using newer technology, possibly as a way to learn the technology while duplicating functionality. Rewriting might even become cost-effective: If the legacy app is written in a language that imposes per-server license and maintenance costs and the rest of the stack has moved over to something more cost effective, getting rid of the ongoing licensing might be desirable.
Lumberjacking With Purpose
When I received the award, those aspiring to win it next were cautioned to not spend weeks holding down the delete key. The purpose is to identify the parts of our system that are wasting our resources, increase our attack surface, or are completely cut off from the rest of the site. By keeping our system simple and free of decay, we can move forward with new features faster, which ultimately helps fulfill our purpose: to code hope.