Green software is a design constraint, not a badge

Sustainability in software is often presented as a reporting exercise: measure emissions, publish a number, add a badge. The more useful version is smaller and more technical. Every unnecessary kilobyte, query, and wake-up has a physical cost, and most of that cost is decided long before anyone writes a sustainability report.

I work in Lagos, where bandwidth is expensive, power is intermittent, and devices are often older than the ones in the design review. That context makes green software less abstract. Efficiency is not an optimisation for a distant future; it is respect for the person on the other side of the connection.

Where the weight actually lives

• Images shipped at three times their display size.

• Client bundles that hydrate components nobody interacts with.

• Polling loops where an event would do.

• Queries that fetch a table to render four fields.

• Animations that keep a phone awake after the screen is idle.

None of these are exotic. They are ordinary defaults, which is exactly why they persist. A green software practice is mostly the discipline of questioning defaults early, while they are still cheap to change.

Efficiency is a user feature

The same decisions that reduce energy also reduce waiting. A smaller payload loads faster on a 3G connection. A cached response survives a flaky network. A page that respects reduced-motion settings is usable by more people. Green engineering and inclusive engineering keep arriving at the same answer: do less work, on purpose.

The most sustainable feature is the one the user needed, delivered once, and never recomputed.

That is the standard I try to hold: not a badge, but a set of constraints that show up in the architecture, the build output, and the way the product behaves on a slow day.