Sustainability and Green Coding as the frontier of digital innovation

How sustainable is our software? A question that CEOs and CIOs are asking more and more often in strategy meetings, and one with a measurable and often uncomfortable answer. Because the software that runs business processes, customer portals, ERP systems and e-commerce platforms has a real energy footprint, which translates into operating costs, CO₂ emissions and, increasingly, regulatory compliance risks.

Against this backdrop, Green Coding is establishing itself as one of the most concrete drivers for bringing IT into line with environmental and business goals. Let’s look at it in detail.

 

Software is not neutral, far from it!

For years we talked about sustainability in terms of buildings, transport and supply chains. Digital seemed immune to the problem: no fumes, no visible physical waste. But the data tell a different story. The IT sector is now responsible for between 1.8% and 3.9% of global greenhouse gas emissions, and with the race towards AI, cloud and big data this share is set to grow significantly over the next decade. According to some estimates, the world’s data centres alone already consume more energy than the whole of Italy.

The cause is not just hardware. It is also, and above all, the software running on that hardware. Every line of code that is executed consumes energy. Every redundant API call, every unoptimised query, every job scheduled for no reason, every microservice left running with no load: all of this has an electrical, economic and environmental cost. Multiplied by millions of executions a day, the result is anything but negligible.

Green coding stems from exactly this awareness: software is not an abstract entity, but a machine that consumes physical resources. And like any machine, it can be designed to consume fewer of them.

 

What Green Coding is (and what it is not)

Green coding does not mean writing less code. It does not mean going back to the minimalism of the 1990s or giving up the functional complexity a modern application needs. It is something more precise, namely designing software that does the same job while consuming fewer computational resources. In practice, for a company this translates into concrete action on several levels:

• Eliminating code bloat. Over time, every system accumulates superfluous code: dependencies that are no longer needed, features that have been retired but are still active, background processes that nobody ever removed. This then weighs on build times, increases the attack surface for security and, above all, consumes resources every time the system runs. A periodic code audit is the first step.
• Choosing architectures proportionate to the problem. One of the most expensive mistakes of recent years has been adopting microservice architectures for systems that had no real need for them. Every additional microservice means more containers, more networking, more orchestration, more overhead. In many cases a modular but monolithic architecture is more efficient, in energy and in operations. The choice of architecture should be driven by real requirements, not by technology fashions.
• Optimising algorithms and data access. A badly written database query can consume a hundred times more resources than a well-designed one. For example, an O(n²) algorithm where an O(n log n) one would do multiplies the computational load exponentially as the data grows. These problems exist in almost every legacy system, and fixing them has an immediate impact on costs and performance.
• Designing for lazy execution. Running only what is needed, when it is needed. Loading data on demand instead of preloading everything. Using the cache intelligently. Avoiding continuous polling where events would be enough. These are well-known principles, but they are rarely applied systematically with energy efficiency in mind.

 

All of this is software engineering done well, with one additional criterion: resource consumption becomes a quality metric on a par with functional correctness and maintainability.

 

The key: energy efficiency is economic efficiency

Here lies the strategic point that is often underestimated in company boards: optimising code reduces operating costs in a direct and measurable way.

Fewer CPU cycles, less allocated memory, less network traffic generated: all of this translates into lower cloud bills. For companies running on AWS, Azure or GCP infrastructure, cloud spending is now a significant item on the P&L. It is not unusual for an in-depth analysis of production code to reveal waste of 20-40% in allocated resources (resources paid for every month without anyone noticing).

At a time when CFOs are looking ever more closely at the cost of digital infrastructure, green coding goes from being an ethical choice to a financially rational one. The ROI of a software optimisation project can often be measured within a few months.

Then there is the dimension of resilience. Efficient systems are by definition more stable, since they scale better under load, have fewer points of failure and recover faster from anomalies. An oversized and inefficient architecture is also a fragile architecture. Companies that have suffered service outages during traffic peaks, such as promotional events, product launches and seasonal campaigns, know the real cost of inefficiency well.

And then there is the user side, often underestimated. An optimised application is also a faster application. Shorter loading times, lower latency, a smoother experience. Studies by Google and Amazon show that every additional 100 milliseconds of latency has a measurable impact on conversion rates. Sustainability and product quality, in this case, are not in tension: they point in exactly the same direction.

 

Green Coding is not only the developers’ responsibility

One of the most common mistakes is to delegate green coding to the technical teams as if it were purely an implementation matter, solvable with a bit of refactoring and a few good coding practices. It is not or rather, not only.

Like any real organisational transformation, it requires a cultural change that starts at the top. In concrete terms, this means taking the conversation about energy efficiency out of code reviews and into product and architecture decisions.

This means that when a product manager asks for a feature to be added, someone in the room should ask: what is the computational cost of this choice? It means that a development team’s KPIs should include efficiency metrics, resource consumption per transaction, average execution time, bundle size, and not just delivery speed and test coverage.

It also means rethinking DevOps processes with sustainability in mind. Today there are tools that measure the carbon footprint of a CI/CD pipeline, that profile the energy consumption of an application in production, that compare the efficiency of two alternative implementations before deployment. Integrating them into the daily workflow is an organisational choice before it is a technical one.

The role of management is also decisive. Without a clear mandate, without energy efficiency being an explicit goal in technology roadmaps, green coding remains a voluntary initiative by the odd conscientious developer. With a mandate, it becomes a systemic and measurable practice.

 

Sustainability: from compliance to competitive advantage

Many companies approach sustainability for regulatory reasons. The European CSRD, the new directive on sustainability reporting that applies progressively from 2024, requires the disclosure of data on the environmental impact of operations, including digital ones. The demands of ESG investors, pressure from enterprise customers in vendor qualification processes and the award criteria in public tenders are factors that make digital sustainability a real business issue and not just one of reputation.

But the organisations that go beyond compliance, that is, those that build sustainability into everyday design and architecture decisions, create something more lasting and strategically relevant.

1. A competitive advantage on costs. More efficient systems cost less to run, and this advantage accumulates over time. In markets with tight margins, the difference between an efficient architecture and an inefficient one can be decisive for profitability.
2. A differentiating position with customers and partners. The ability to demonstrate, with data in hand, the environmental footprint of your software is a growing differentiator. Large industrial groups and multinationals are starting to ask their technology suppliers to report on the environmental impact of the software delivered. Those who come prepared for this conversation win tenders that others do not even realise they are losing.
3. An advantage in attracting talent. The most skilled developers increasingly choose companies that work with sound engineering practices and consistent values. Green coding is also a sign of technological maturity and of a culture of work done well.

 

The data confirm it: companies that invest in digital sustainability show better economic performance over the medium to long term. This is the result of organisations that think systemically about efficiency.