← All field notes

Green Software Without the Vague Claims

Reduce unnecessary processing, storage and data transfer while keeping the product useful. Report measured engineering changes separately from broader environmental claims.

Software

Environmental claims about software need evidence. A faster page or a smaller cloud bill can be a worthwhile engineering improvement, but neither directly establishes how much energy or carbon was saved.

Begin with work the team can observe: processing time, storage growth, data transferred and the hardware needed to run the product. Reduce waste there, then describe the result within the limits of the measurement.

Measure the work that matters

Look at how often tasks run, how long they take and which resources they use. “Compute” refers to the processing performed by a computer; usage and billing information can help locate expensive work without acting as a direct energy meter.

Choose a representative period. Include busy periods, overnight processing and recurring reports where relevant. A baseline should cover the workload being changed so the comparison remains meaningful.

Remove work that no longer serves a purpose

Review unused scheduled jobs, duplicated processing, abandoned environments and information kept without a retention reason. Establish ownership before removing them.

Reuse expensive results where it is correct to do so. Consider whether a system needs frequent checks for changes or can respond when a change occurs. Any adjustment still needs to meet the product's freshness and reliability requirements.

Include efficiency in product decisions

Review image sizes, page downloads, background requests and the work triggered by common actions. Agree practical limits that fit the product, then check them alongside usability and accessibility.

Efficiency should preserve useful behavior. A smaller download is only an improvement if people can still read the content, operate the controls and complete the task.

Test on the devices people keep using

Check realistic lower-powered hardware and watch memory use during longer sessions. Avoid making an application unnecessarily demanding when simpler approaches serve the same purpose.

On servers, match capacity to the workload and its reliability needs. More capacity than required carries a cost, but removing it without understanding peaks can create service failures. Supported dependencies and clear documentation also help software remain maintainable.

Report the change precisely

Keep the baseline, method, dates and relevant workload conditions. State what was observed, such as fewer repeated jobs, less transferred data or lower processing time for the same task.

A carbon claim needs additional information about factors such as the hardware and energy supply. Keep that uncertainty visible rather than converting a billing change into an environmental result. A modest, reproducible engineering improvement is more useful than a broad claim the evidence cannot support.