What steps can a software company take towards sustainability?

The hype around sustainability is intense and cluttered.

Sustainability is a multifaceted topic and for many a so-called wicked problem. But is it really? How can we find the right means and methods to become a company that is not causing harm to this planet? A big question, but there are some existing validated answers and solutions to it.

Luckily, there are things we can achieve with simple changes in what we do, how we operate, and how we think, to make a truly positive and measurable impact. People often forget one thing, though. It’s how systemic and multifaceted sustainability is in its nature. True sustainability requires systems thinking and a comprehensive understanding of technology, design, the environment, and your business' effects on it.

At Fraktio, we create digital services with interfaces in browsers or apps. We design them to be usable by a wide array of people with different backgrounds and capabilities. There's a lot to do here, sustainability-wise. Carbon emissions, directly and indirectly, inform us of the level of harm services and our actions have on our environment. The further we travel from the computer that runs our software, the harder it is for us to prove the effectiveness of our sustainable actions.

How can you make your digital services more sustainable?

5 ways to shift towards sustainability in tech

You can make the most straightforward and measurable changes by considering these five areas to shift towards more sustainable tech.

Hardware and infrastructure
Software development
Design
Service lifecycle
The solution and its second-order effects

1. Hardware and infrastructure

When used intelligently, modern and scalable infrastructure can eliminate waste, costs and emissions.

It’s natural to start where we can measure carbon emissions and most effectively change how we generate them. The software runs on a machine and machines use a lot of energy. If you’re asking how much energy is used on what and why, you can start observing how optimised the hardware and infrastructure you’re using are. The machine can be a server, a laptop, a phone, or an array of machines called the cloud.

First, let's consider what happens on the backend side: on a server or in a cloud. A server is generally a fixed cost and fixed performance asset that we can optimise to do things as effectively as possible. The problem with a server is that it should be running at near-full capacity all the time for it to be both cost-efficient and environmentally friendly. Many services do not require 24/7 server utilisation.

An adequately set up cloud infrastructure can provide its user with a high-performance environment, but only when needed. A dynamically scalable environment has cost-effective and environmentally more sustainable use of electricity and hardware materials. The platform provider can internally optimise how their customers utilise which resources.

In theory, these platforms can run code in areas that currently provide the cheapest electricity and have the most processing power available. Imagine spawning a cloud instance in a region where wind power creates affordable, sustainable energy. Do this at night, when traffic from this region's users is naturally smaller.

Cloud-enabled scalability has its issues too. It is often easier to crank more and more performance from a cloud console than installing new servers on a physical server farm. It's simpler than delving into the workings of software or anything that requires manual effort and time. We need to weigh what problem we should be spending our time on and which solution is sustainable in the long run.

2. Software development

Optimising software for speed and usability improves user experience and reduces emissions. Avoiding wasted labour in bug hunting and error scenarios also decreases emissions.

Running software is a proxy for consuming electricity, which is a proxy for emitting carbon.

Optimise code

The most obvious thing here is optimising the code that takes the most time to execute and detrimentally affects the end users' experience. Optimising the code means that the faster things work, the less they consume computing time. Speed is yet another win-win-win situation:

The end-user is happier
The infrastructure costs are lower
The environmental effects are less cumbersome

You can optimise the amount of data transferred or optimise how the data is processed. Processing happens on both service and user ends.

How to optimise the amount of data transferred to users?

You can optimise:

picture size (check out WebP)
fonts
compression
lazyloading
package handling and dead code elimination

These are the things we focused on in the early '2000s. A user on a modern high-end device with a broadband connection might not notice such improvements, but cumulatively, these things add up.

How to optimise how the data is processed?

On the processing and execution side of software, we have things such as

caching on several layers
database query optimisation and data handling
dead code or useless repetition
language selection, from speed, popularity, and composability point of view

Poor performance on these affects page load or request response times. The same cumulative logic on costs applies.

Testing in a fresh test environment is crucial for optimisation

Writing and running tests is an effective way of preventing errors and avoiding waste. Aiming at finding errors as soon as possible helps to avoid encountering them later in the development, test, or use cycle, and naturally wasting everyone's time in the future. Make you sure you have a fresh and repeatable environment to run these tests for them to be accurate.

Storage space, like bandwidth, seems limitless, but in reality, it is not. Storing data and backups without a proper plan to manage and purge them is lunacy. This problem is yet again made easier and exacerbated by cloud tooling. Enable automatic backups, but don't store everything indefinitely. Storage doesn't actively use that much energy, but creating storage does require natural materials.

Many of the improvements mentioned above reduce the amount of computing, data transfer, and need of storage. These translate into direct or indirect cost-effectiveness. Making these improvements cost time, but they pay themselves back in cost-effectiveness. Cost-effective, minimal, and optimised systems strain the environment less.

3. Design

Design decisions can affect how much data is transferred and how much screen time drains electricity. The better the user experience, the less time is wasted, and fewer emissions are generated.

Sustainability on the end user's part is less technical and more in the realm of behaviour and accessibility. Still, let's see a few things we can at least theoretically measure.

If you pay attention to your phone's battery usage, you might notice how much energy its screen uses regardless of the applications. That's because white and blue pixels drain most energy. While dark mode might seem like a gimmick, it's actually a feature that optimises energy consumption.

Compressing images frees up bandwidth, but using fewer images frees it up even more. Making things work in dark mode and with fewer images takes up some design effort, but it's worth it.

Most sustainable design decisions affect carbon emissions indirectly. Many of the efforts are related to usability. Ease of use translates to less wasted time and effort.

When users produce erroneous scenarios, they also waste other people's time. Error scenarios, especially poorly handled ones, generate work to end users and customer satisfaction teams. This work was not necessary, to begin with, but something avoidable with better design. Ordinary business sense should encourage good design and usability, regardless of eventual emissions.

Accessibility and inclusion are becoming standards, and rightly so. We can rarely improve either of these themes with either-or solutions. Instead, people land on a spectrum based on their background and situation. There is no clear-cut level of standard mental and physical capability that some ideal human being has while using any service. Things being on a scale, we can start small and iteratively improve usability and accessibility for all.

Again, by improving your design to serve a more extensive user base, you tend to make decisions that enhance usability for everyone. General usability improvements eliminate waste. It is yet again good for business.

4. Service lifecycle

Proper lifecycle management and care can avoid major rewrites or difficult maintainability, creating savings in both expenses and time; and, consequently, in emissions.

Lifecycle affects labour costs. Labour generates emissions. Useless changes waste time, as does the maintenance of a semi-broken service that would be better replaced.

There is no one solution or a fixed timespan for a digital service's lifecycle. We should build these services to last. To be maintainable and improvable. Not just by us ourselves but by unspecified people with unspecified knowledge and skillsets and at an unspecified time in the future.

What matters here is craftsmanship. All experts should care about their work - not just the visible layers but the unseen things too. Is documentation sufficient? Security? Efficiency? Maintainability? Test coverage? Well-cared-for codebase, design system or infrastructure can be improved upon or passed onto new people. A haphazard mess of unrelated features glued together with hopes and dreams cannot.

A team working in a DevOps culture makes sure there are no silos. No renegade cowboys working alone with features, infrastructure, or documentation. They ensure the whole project stays healthy through shared best practices, high expectations, and unified pride. This is craftsmanship shared by a team.

The people building the service should forecast a lifespan for the service in question. How long will the service last, and at what point will we discard or rebuild the service? Rebuilding any service from scratch is often costly and complicated. It is more challenging and expensive than actively maintaining systems to meet demand and refactoring software to match current best practices.

However, for most solutions, there comes a time when a complete or partial rewrite is the only sensible option. Sometimes, a new service consolidates several old ones, solving several issues with software decay and rising unhealthy maintenance costs. If a product roadmap can predict this, all the better.

5. The solution and the second-order effects

Systems thinking and ethics dictate decisions on what to build in the first place.

The built solution itself can have massive second-order effects far beyond the scope of direct carbon emissions. A well-made and well-meaning product can affect people's behaviour in ways that make the users act more environmentally friendly. Likewise, any solution can also do the opposite.

Therefore, it always matters more whether the solution and the motives behind it are ethical, moral, and environmentally sound. Any technical optimisations for a product that drives bad behaviour or emissions outside the digital realm and its enablers are not good in the planetary books. Any good meaning service can be (temporarily) forgiven for unoptimised technical or design decisions if the second-order effects improve the environment or society.

One counter-intuitive but increasing need for a digital service is using it less. This contradicts the gamification and "more attention is better" mindset.

Wasting people's time and money for personal profit is an issue that affects physical and mental health, as well as productivity.

At this point, we can no longer deduce that good business is good for the environment. Instead, we say that ethical and, in a sense, mindful business is good for the environment. We are in the domain of systems thinking and wicked problems.

Trying these things together

Start from the second-order effects and move towards details and technical optimisations.

Now, this is all backwards; you might have noticed. It is better not to build a useless or harmful service than to build it technologically sustainably. It's better to plan for a long lifecycle instead of rebuilding everything and doing it often. It's better not to implement a nice-to-have feature if you can design your way around the issue and accomplish the action in another way.

Start thinking about the second-order effects, the product, and the users. First, make sure the solution is a positive force in the world. Only then, tinker with the technological optimisations.

All levels and roles of a company should take sustainability seriously. Partly applying these principles, while better than nothing, can be seen as hypocritical. At worst, it can create internal disputes.

Most reading this need to take care of their business first. Yet, after taking care of the profits, take care of the planet.

Resources: