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
- Less webpage bloat, less cycles spent on network & parsing -> less power consumed
- This is an easy target because modern toolchains make it easy to make your website BLOATED AS HELL
- in a mobile-first world reducing network and battery consumption is both respectful of the network AND of the user
- Do you really need a tracking script?
- Do you really need a front end framework that is several kilobytes gzipped?
- Do you really need to enforce client side hydration and prefetching of adjacent pages? (Looking at you here Gatsby)
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
- Is there a moral imperative to enforce dark mode by default? It would in aggregate result in much less power consumed by displays. It may also be more respectful of users eyes? This would need to be coupled with respect for the users' accessibility needs.
- Am I being a bad person by not dutifully trimming my blog pages down to a minimum of just the content?
- Can we come up with some sort of measure of a website's efficiency based on the ratio of actual, requested content (e.g. the text of article found by search) to the total size of all assets delivered when an average browser loads the initial url. An even better metric would include any work done to serve the page but that is harder to measure.
- Have ad-blockers, insofar as they improve the above ratio, been a huge win for the environment?
- Is it possible to enact legislation to internalize some of these externalities? Could we enforce some penalties based on efficiency ratings of the type mentioned above?
- Do browser vendors have a moral imperative to offer a "low impact" mode that blocks absolutely everything that is not esssential information, and loads things as lazily as possible?
- If I browse the web from emacs does it work like this?
- Firefox reader mode is a step in the right direction.
- You should be able to reject loading styles altogether and only load content which is styled using user agent styles (which should be customizable per page, with sensible defaults, and accessiblity settings.)
- One could imagine a browser extension/plugin that does this.
- It would also be an opportunity to fix bad UI patterns. If you are only ingesting content you can determine the UI that presents that content.