Christian Heilmann

Terseness tension

There is a strange fascination in developers to keep things as small as possible. There are several reasons for it. In the past, computers had limited resources, so every byte had to count. On the web, we never know what people use to consume our code. Erring on the side of caution is also a good plan there. One virtue of every good developer is also laziness. This translates to fewer words and keystrokes.

Another reason for short code is that we drum up excitement in blog posts and presentations. Screen space isn’t plentiful when you want people at the end of the room to read. And people online are busy and don’t want to go through long-winded code examples.

Over the years in my career, I started not believing in short code as a goal any longer. There are a few reasons why we shouldn’t celebrate it as much as we do:

The biggest flaw in the shorter is better thinking to me is that it assumes an outdated idea of development. We’ve come a long way in delivering code to our end users. Instead of writing live code there are a lot of sensible steps we can take. Linting the code for issues even before we add it to version control. Writing tests and validating the code against erroneous input. And converting and packing the code to be smaller in production than it is in development. Tools are great at shortening code to be more effective and even parsers and engines do their bit. JavaScript engines do a lot of optmising and caching of code. Thus a seemingly long piece of code can run faster than something that has been optimised prematurely.

So am I telling people to write more and overly wordy code? No, you can do whatever you want. But I wished we considered where the code runs and who maintains it before declaring smaller the winner. And I see a lot of effort and praise being wasted on code that looks impressive but wouldn’t work out well in production.

What counts in the end is what our end users have to download and how it executes on their devices. Twenty lines of “clever” dependent on a high-computation library of 2 MB or more is not good service to our users. A hundred lines that deliver a good experience loading more when and if the environment and connection allows is good service.

By all means, let’s keep impressing each other with short, clever code. But let’s also consider the long term effect of making this a goal. We now still have a lot of web products dependent on jQuery, probably the starter of “write less, achieve more”. Many of those products aren’t maintained any longer. The libraries they depend on have security holes that won’t get patched. Blindly following a “less is more” approach we created a lot of technical debt.

The other problem I keep running into is lots and lots of “short and quick” solutions being piled on resulting in a huge final product. Just because the smaller parts something big has been built with are optimised doesn’t mean it results in an optimised final product.

My approach to development is the same I take when it comes to writing. I write as much as needed to keep it understandable and easy to follow. I deliberately use simpler words when more complex, but terser ones could confuse a reader. I go through my written products a few times and remove cruft as I go. I don’t pretend that I could write the perfect post right off the bat. Instead making things smaller as you re-read it is a positive experience I enjoy.

Let’s applaud excellent solutions for our users, not things that are impressive but only applicable in the environment they are shown.