Code As a Liability

I’ve worked with some great engineers in my career. Perhaps the one that I consider to be the most focused, driven, thoughtful, and effective had a really interesting approach to code — one that I try to carry with me today.

His approach to code was to eliminate as much of it as possible. He prided himself on how much code he could remove from a codebase while still keeping it functional and comprehensible. He always said that code is a liability. And he was right.

A codebase is a necessity for many companies today. It defines the work product produced by that company. In some ways, not in all, but in some — a technology company is its code.

Most engineers love to write code. It’s a great feeling to push out a piece of well-tested, clever, and effective code that solves a real problem. However, most engineers, at least in my experience, don’t care too much to clean up and remove old code. For many, it’s not a priority (for the best ones, it’s the major priority).

To me, it makes complete sense to try to reduce the size of a codebase as much as possible. Products frequently get sunset. Code gets old and becomes obsolete. Old methods can get longer without being refactored. All of these become maintenance and performance nightmares with a long enough passage of time. And code maintenance equals a decline in business productivity, with then becomes an increase in R&D expenses.

Keeping a codebase as lightweight as possible allows engineers to reduce the amount of time they need to spend on maintenance. It’s far easier to read through a class file that’s 200 lines of code that’s still used, rather than having to go through a class file that’s twice as long that may have unused methods, or a mixture of actively used methods with unused methods and methods that are marked as deprecated. The mental burden on a software engineer grows dramatically with the amount of code that he or she needs to understand. So in that sense, less code means better developer productivity.

A smaller codebase also leads to less intrusive test suites and CI builds. By eliminating code that’s no longer needed, it’s possible to remove a large number of tests that no longer need to be run, allowing your build system to complete more quickly.

In my mind, better comprehensibility and better build performance are the two most important reasons to keep a codebase as small as possible. I’m sure there are many others, though.

So, even though code is 100% necessary to run a tech business, a company’s approach to code can determine part of their tech team’s efficiency. When code is looked at as a liability, and engineers are encouraged to reduce the codebase as much as possible (while still maintaining comprehensibility), it’s a win for the entire business.