The Morality of Efficiency

Is there a moral obligation to strive for efficiency?

Software's dirty secret

The software industry has more than a few warts, but the one we'd like to focus on in this article relates to the efficiency of the code we produce, or what is referred to in the industry as performance. While the programs we use are generally much more feature rich than they were in the past, the efficiency with which they run has continuously declined.

There are a few reasons for this. One is that we are simply building bigger and more complicated applications to tackle harder problems. These applications in some cases do more actual work than the applications from previous generations, and therefore consume more resources. Some people may argue that some of the new features causing this type of bloat are unnecessary, but let's consider this type of bloat justified for now so that we can focus on the other types.

Another reason is that computing resources like energy, cpus, and memory are cheap and always getting cheaper, while human resources are expensive. In order to build and maintain increasingly complex applications using the same or fewer number of software developers, the industry has prioritized improving developer experience over improving efficiency. In fact we often explicitly trade ease of development for worse performance. For example, new frameworks make it easier to build large software projects, but in doing so they require more computing resources such as memory or cpu cycles.

The last reason we'll consider in this article is that there is a higher bar for what constitutes good user experience now. Surpassing that higher bar sometimes requires sacrificing efficiency in one way or another. That being said, perceived performance is part of user experience too, so the questions is usually not so simple. Consider websites that prefetch linked pages before you visit them, so that when you click on a link you are navigated to that page near instantly, without having to wait for a network request. This increases the perceived performance of navigating between pages on the site, but causes the user to fetch more content than they actually want or will view, decreasing the memory and power efficiency of the site.

One might notice that none of these reasons are cut and dry bad things. They are all trade-offs. It just so happens that due to a variety of factors, we consistently sacrifice efficiency when facing these decisions. That being said I think there is some real value to be gained from being slightly more aware of efficiency and respectful of consuming a users resources.

The Cost of Poor Efficiency

Running computer programs requires energy. Most people understand this, but don't feel it until their phone battery is dying. The amount of energy required to operate a phone is so small relative to the amount required to operate a car that the average U.S. citizen doesn't mentally associate any monetary cost to say, opening a website. Things are different in developing countries where bandwidth is precious and expensive, but even there the energy cost in dollars is often considered negligible.

However, running out of battery, or bandwidth, or memory is just about the worst user experience there is. Here, mobile computing gives us an example of an environment where computing resources are scarcer and more precious. Network requests especially are more expensive for mobile devices. In such an environment we should shift the balance of the trade-offs mentioned above slightly more towards efficiency. This means that when designing software for mobile platforms we should be willing to put in more man hours building our software to ensure we are efficient, and also that pre-fetching resources to simulate instant page loads might actually be a worse user experience overall than only fetching what is needed due to the increased cost of network usage in terms of battery and bandwidth.

Webpage Bloat is low-hanging fruit

The Cost of Externalities

As we have discussed above there are real costs to inefficient code. Actual things will happen in the real world to the detriment of our planet's carrying capacity for human life if, on average, we undervalue performance and underestimate resource costs.

However, we as writers of code rarely bear those costs, or even think of them. In the unending rush to push out more features there are many noble concerns that often don't get the full attention they deserve. These include security, correctness, system stability, ux polish, accessibility, privacy etc. Most organization prioritize these things in a different order but usually all less than new features (there are exceptions.) I would say that in my experience performance usually falls towards the bottom of this list as long as the product is still generally usable at the current performance level.

The Questions this line of thinking raises

Flatpak Is Not The Future