Software belongs in the green IT debate because it helps determine how much electricity organisations consume and how much hardware they need. CIOs should treat those consequences as part of the investment decision, from initial procurement through to retirement.
Code does not emit carbon in isolation. Running it consumes resources, and decisions about applications, architecture and data influence the scale of that consumption. Software is the demand side of IT energy use. It determines what work we ask infrastructure to perform, how frequently and at what scale.
Demand as an accounting challenge
There is no credible universal percentage for software’s contribution to an organisation’s carbon footprint. Its significance varies with the business and its workloads. There is also an accounting challenge. Software drives consumption already attributed to electricity, hardware and cloud services. Adding a separate software footprint to those figures could count the same emissions twice. The useful question is how much of that demand could be prevented by better software decisions.
An application that repeatedly processes unnecessary information or keeps resources running when they are not needed creates an ongoing burden. When additional cloud capacity is readily available, expanding provision can be easier than investigating the underlying demand. The organisation then pays to accommodate inefficiency, financially and environmentally.
Evidence shows that improvements can be meaningful. An Accenture industry case study presented at the IEEE/ACM Automated Software Engineering conference in 2023 reported a 29% reduction in energy consumption per user, per month after refactoring energy-inefficient code patterns in a large application. This was a result from one application, rather than a universal saving or a reduction in the organisation’s total footprint. It nevertheless demonstrates why software efficiency deserves measurement and attention.
Preventing software-induced hardware churn
The relationship between software and hardware replacement deserves particular scrutiny. Higher processing requirements, increased memory demands or changes in compatibility can turn an application upgrade into a substantial equipment purchase. The environmental implications therefore extend beyond the electricity used to run the software.
Before approving that purchase, leaders should establish what is driving it. Is the existing equipment genuinely unable to meet business requirements? Could a targeted upgrade extend its useful life? Have alternative applications been considered? Does the additional functionality justify the resources it requires?
Security, support and reliability must remain central to that assessment. Extending equipment life is responsible only while it remains fit for purpose. Equally, replacement should follow evidence rather than an assumption that each new software generation requires new hardware.
Wirth’s law – the observation that software becomes slower more quickly than hardware gets faster – shows the risk of increasing software demands absorbing hardware improvements. For business leaders, it raises a practical question. Namely, how much new capacity supports useful activity, and how much accommodates avoidable complexity?
Embed efficiency into governance
CIOs are responsible for making that question part of normal governance. Teams assessed solely on delivery speed, availability and new functionality will struggle to prioritise resource efficiency. Leadership must provide time to address it and make it part of how technology investments are evaluated.
That responsibility includes reviewing the application estate. Organisations should challenge overlapping systems, unused functionality and services that continue running without a clear business owner. Retiring an unnecessary application, with appropriate migration and retention arrangements, belongs alongside improving the applications the business still needs.
Procurement teams should apply similar scrutiny to purchased software. Hardware requirements, support periods and compatibility all deserve consideration before a contract is signed. Suppliers should also be asked for evidence of resource consumption relevant to the product being purchased. A corporate sustainability commitment provides limited insight into the efficiency of a particular application.
Architects shape many of the larger decisions about demand. Availability, replication, processing frequency and scaling should reflect actual business requirements. Some services need immediate processing and continuous availability while others can operate on a schedule or use less capacity outside working hours. These distinctions should be established deliberately.
Developers need the tools and time to measure the consequences of implementation choices. Resource consumption should feature in testing, particularly for frequently-used functions and intensive workloads. Effort should follow evidence – a modest improvement to a process executed millions of times may matter more than extensive changes to a rarely used feature. Cleaner-looking code alone does not prove an environmental benefit.
Accountability for data and measurement
Data requires accountable ownership too. Organisations should understand why information is collected, how long it is needed and how many copies are justified. Retention and replication must support business, security and recovery requirements. Indefinite accumulation should not be the default simply because storage appears inexpensive.
Measurement connects these responsibilities. The Green Software Foundation’s Software Carbon Intensity specification incorporates energy consumption, electricity’s carbon intensity and an allocation of hardware’s embodied emissions, expressed per functional unit, such as per transaction. Organisations should also track absolute emissions. Improved efficiency per transaction does not guarantee a smaller overall footprint if usage grows substantially.
Code optimisation must nevertheless remain in perspective. Cleaner electricity, better infrastructure utilisation or different hardware decisions may offer greater savings in a particular environment. Priorities should follow measured opportunities. Software design can also enable carbon-aware scheduling, and allow suitable workloads to run when or where electricity has lower carbon intensity, subject to operational requirements. These approaches can reinforce one another.
Responsibility should follow influence. CIOs set priorities; architects shape resource demand; developers influence execution; buyers challenge suppliers; and business owners determine which services and data are necessary.
Before buying more capacity or replacing more equipment, an organisation should be able to explain why it is needed, what alternatives were considered and how the outcome will be measured. Understanding the physical consequences of digital decisions is sound technology management. It should also be an essential test of credible green IT.
Daniel Smith is CEO of Astralis Technology
