Green software is mostly just good software

Green software has a reputation for being a specialist field, with its own tools, its own vocabulary and a separate budget. In our work it is mostly something simpler. The software that uses the least energy is nearly always the software that does the least unnecessary work. And software that does the least unnecessary work is cheaper, faster and easier to run.

That is good news for anyone who has been asked to cut emissions and costs in the same year. In most estates the two point the same way.

Where the energy goes

Software uses energy in three ways: when it computes, when it stores data and when it moves data across a network. In the estates we have measured, the largest share of that energy goes on work that nobody asked for. Servers that wait. Copies of data nobody reads. Services that ask each other the same question a thousand times a minute.

• Idle environments: test and staging systems left running nights and weekends.
• Oversized servers: capacity bought for a peak that comes twice a year.
• Chatty services: calls between systems that could be batched, cached or removed.
• Data kept forever: logs and copies stored in fast storage long after anyone needs them.

70%Typical share of hours in which non-production environments sat idle, in the estates we measured.

Start with the hours nobody uses

The quickest saving is almost always the same. Non-production environments run around the clock, but people use them during working hours. Switching them off at night and at weekends cut compute hours by 38% at one manufacturing client, with no change to a single line of application code. The cloud bill fell by a similar share.

The next saving is usually in the code. At a regional retailer, one product search query was responsible for a fifth of the database's load. Rewriting it took two days. CPU use on the database fell by 60% and the search page loaded in half the time. Nobody had looked, because the page worked.

“We went looking for carbon and found performance problems. Fixing them did both jobs at once.”

Carbon as an engineering measure

Teams improve what they can see. Latency became a habit when every team had a dashboard showing it per request. Carbon can work the same way. We help teams estimate the energy and emissions per transaction, per order or per report, and put that number next to latency and cost. It does not need to be precise to be useful. It needs to move when the code changes.

Two choices outside the code matter too. Where a workload runs changes its footprint, because grids vary widely in how much carbon each unit of electricity carries. When it runs matters for work that can wait: a nightly batch can often move to the hours when the grid is cleanest, at no cost to anyone.

Where green and good disagree

Not every choice points the same way. Running a system in two regions for resilience doubles part of its footprint. Keeping data for regulators means storing it. These are good decisions, and we would not reverse them. The point is to make them on purpose, knowing the cost, rather than inheriting them from a default nobody chose.

Green software is not a separate discipline to bolt on. It is a reason to do the things good engineering teams already know they should: measure, simplify, switch off what is not used, and look at the slow query.