Image: iStockphoto/Viktoriia Hnatiuk

Blessed are the code committers to open source projects. But more blessed are they who delete, for theirs is the kingdom of clean, efficient code.

No set of scripture contains this wisdom, but that doesn’t make it any less wise. As developer Dj Walker-Morgan has posited, “For me, deleted lines are the final burn down of the ground where tech debt built.” To delete lines of code requires deep familiarity with the code base and, as such, reflects some of the best (un)engineering possible for a project. Similarly, as Charity Majors has stated, “The best senior engineers I’ve worked with are the ones who worked the hardest not to have to write new code.”

Is there any way to properly celebrate those who delete or who write less in order to deliver more?

SEE: How to build a successful developer career (free PDF) (TechRepublic)

Getting real about technical debt

While technical debt is often characterized as the result of “taking an easy but suboptimal decision in the software development process,” I like Dormain Drewitz’s suggestion that “all code is technical debt.” Why? Because it’s easy in hindsight to negatively classify code decisions and the resultant cruft, but at the time of writing the code there might not have been a better option. Indeed, it might have been the absolute best option at the time.

But that doesn’t mean it needs to persist.

However the “debt” accrues (put aside for the moment whether you like/dislike the term and whether, as RedMonk’s Rachel Stephens rightly argues, the term is incomplete), Martin Fowler’s advice on how to tackle it resonates:

[U]sually the best route is to do what we usually do with financial debts, pay the principal off gradually. On the first feature I’ll spend an extra couple of days to remove some of the cruft. That may be enough to reduce the interest rate on future enhancements to a single day. That’s still going to take extra time, but by removing the cruft I’m making it cheaper for future changes to this code. The great benefit of gradual improvement like this is that it naturally means we spend more time on removing cruft in those areas that we modify frequently, which are exactly those areas of the code base where we most need the cruft to be removed.

I really like Sarah Mei’s description of technical debt as “clutter” (like a messy house). For those that think such clutter/debt is whisked away by moving to a microservices architecture, it doesn’t. Not really. Mei wrote: “[Y]ou end up with an overstuffed smaller house and a bunch of disorganized storage units, and you STILL can’t find anything.” Following Fowler’s advice, perhaps the ideal way to tackle the debt/clutter is to work on those areas that see the most contributions.

Which brings us back to how we can properly acknowledge those that delete.

Another way to contribute

Image: Matt Asay

If you look at the Cloud Native Computing Foundation (CNCF) leaderboards for Kubernetes or other projects, it’s easy to see who contributes code: On that drop-down menu there is no mention of “Lines of code deleted” or, following Majors, “Engineers who worked hard not to add lines of code.” Instead we track those that contribute, who commit, new code. There is value in this, but I worry that it doesn’t capture a huge area of value for open source projects.

It also does a shoddy job of measuring significant code versus just volume of code. That’s a difficult measure in practice, but also important. But let’s get back to the art of deleting code.

As my former colleague Henrik Ingo told me, “During 3 years in MongoDB engineering I’ve deleted more lines than I’ve added.” He then adds, tongue-in-cheek, “Alas, it’s a losing battle. Only invigorates team mates to add thousands more.” The best engineers may not show up high on the list of contributors because their contributions are about intelligently removing cruft as much (or more) than about adding code. (Years ago Yelp’s engineering team wrote about a tool they built–Undebt–to “perform massive, automated code refactoring.” I’ve not seen an update or whether others have successfully used it.)

I’d love to learn how you or your organizations discover and elevate those who delete. Is there a way that we could be doing that for open source projects, too? I know it’s always an imperfect science (or perhaps pointless) to come up with leaderboards but so long as we have them, I’d like to see more emphasis given to those who help remove the technical debt/clutter in our collective code.