As an experienced software developer, your goal should be to write as little source code as possible. This probably sounds opposite of what your intuition tells you, as writing source code is literally in our job description. It might even make you think you’d be lazy to do such a thing. Well I say: be a lazy developer!

Source code is a liability, not an asset.

Source code is a liability, not an asset. This is a phrase I often tell teammates when discussing how to solve the next big problem. Let’s unpack what I mean by this.

First let’s define the terms. A liability is something a person or company owes, usually a sum of money (i.e. a debt). An asset is something a person or company owns. The more source code you have, the more you owe, the higher your debt.

Debt is not necessarily bad. In fact it’s necessary for software developers to do their job. Too much debt is where you start to run into problems. When you can’t pay the monthly payment on your software mortgage you’ll default.

The cost of code

So why is source code a liability (debt)? Source code may abstractly represent your assets: algorithms, intellectual property, a web application, a mobile application; but the source code itself is the mortgage you took out to buy them.

It costs time (labor) to create and maintain source code. Having more of it comes with more cost:

  • It’s harder to read code than it is to write it. More source code requires higher cognitive load. Higher cognitive load slows development and also slows onboarding.
  • The more source code you have, the more places there are for bugs to hide.

All code rots

Source code has a shelf life. It must be continuously maintained or else it becomes useless. This is mostly because of the volatile environment it lives in. Third party dependencies go out of support or have security holes discovered. Frameworks and programming languages go out of style. Operating systems are constantly being updated to higher versions.

So what do you do?

So back to the beginning: how do you write as little source code as possible?

When solving a problem, prefer these solutions in order:

  1. Eliminate the problem. Pop the why stack. Redesign until the problem goes away.
  2. Reuse or adapt an existing solution.
  3. Write the simplest possible solution using expressive code.

Write simple code

Always start with the simplest solution. Embrace the KISS Principle. Embrace the YAGNI Principle.

Write expressive code

Expressive code is code that is generally more declarative than imperative. You’re not instructing the computer what to do line by line, but using higher-level abstractions to describe the end result you desire.

For example, say you want to build a query string. Don’t write out string concatenation to build it by hand.

let query = "?foo=" + foo + "&bar=" + bar + "&bat=" + bat.

Not only is this laborious, but it’s also incorrect and insecure. Instead write or find a function to build the query string for you.

let query = buildQueryString({ foo, bar, bat });

Or perhaps you want to find items in a list. Don’t write a for loop.

let results = [];
for (let i = 0; i < numbers.length; i++) {
  let number = numbers[i];
  if (number === 123) {
    results.push(number);
  }
}

Use filter instead.

let results = numbers.filter((n) => n === 123);

Utilize your chosen programming language and all its features. Learn deeply the capabilities of the framework and use them. It’s likely they’ve solved most of the problems you’ll encounter. If the language or framework doesn’t provide something, write a library using npm, NuGet, Maven, or your favorite package manager. To make more effective libraries, learn about fluent interfaces, reflection, composition, and code generation. Doing all these things can lead to a lot less code where it matters.

Write disposable code

Given that all code rots, write disposable code. Disposable code can be discarded or replaced without severely disrupting the overall system.

Monoliths by nature are never disposable. They can easily rot but cannot be discarded. Avoid writing monoliths. Also avoid the patterns that are made for monoliths (Clean Architecture, Onion Architecture) which can lead to excessive amounts of source code. These are tempting patterns to use in monolithic applications to attempt to gain a sense of modularity.

Instead modularize your applications into small components with clean interfaces between them. Components can be discarded and replaced when they rot, and don’t have a need for complex and verbose design patterns. I highly recommend reading The Tao of Microservices by Richard Roger.

Conclusion

Go out there and be lazy. Be proud when you don’t have to write a single line of code. Be prouder when you get to delete code. Be proud of the lean, expressive code that you do write. More is not better.