The same waste, counted twice

Inefficient software does the same thing whether you look at it as an environmental problem or a financial one. It asks for more processor cycles, memory, storage and network traffic than the job requires, and every one of those requests turns into both a kilowatt hour and an invoice. Energy efficiency and cost efficiency are not two initiatives competing for the same budget. They are one piece of engineering work, described in two currencies.

The reason this is not obvious is that the cost never appears under its own name. ISO/IEC 25010 sets out how tightly software quality is coupled to operational behaviour, and four decades of completed project data show what happens when short delivery cycles break that coupling. The consequences are well documented, but they land in eight different budgets.

The eight lines sub-optimal software is paid for on

View full size

• More hardware, more infrastructure and more energy to carry the same workload.
• More maintenance effort, for longer, on code that is harder to change safely.
• Performance and reliability incidents, with the support tickets and downtime that follow.
• Inconsistent implementations of the same thing, each of which has to be learned separately.
• Safety and security exposure, in systems where a defect is more than an inconvenience.
• Lost productivity and slower time to market, because effort goes into keeping the existing system upright.
• Lost customers and eroded margin, when the product is slow, unreliable or late.
• A reduced ability to innovate, because the capacity to try anything new has already been spent.

No ledger has a line called "inefficient software", which is exactly why the total is never challenged. Hosting is the clearest case. Cloud and data centre charges are treated as a necessary cost of doing business and reviewed for discounts rather than for cause, even though the demand that sets them is written into the code. The department that buys software has no control over its performance, and the one that pays the bill never sees the cause.

What it costs to carry, and to clear

Technical debt has been estimated at about $3.61 per line of code. A system of a million lines therefore carries roughly $3.61m of deferred cost that has never been recognised as such, and the interest is paid monthly in the eight lines above.

Clearing it by hand is the reason it goes on being carried. A realistic breakdown, drawn from CAST's research and other industry estimates, puts quality assessment at 0.5 to 2.5 dollars per line, the refactoring itself at 3 to 8 dollars per line, re-testing at 10 to 15% of the refactoring cost, and project management and contingency at a further 10 to 20%. Between 60 and 80% of software in service is legacy. Faced with those numbers, managers defer, and the debt compounds.

One automated run, every line at once

GreenCode automates the work an organisation would otherwise pay people to do, and because it is one pass, the returns arrive together. The pipeline maps the codebase, baselines its quality and refactors the defects, generating the tests and documentation the code was missing. It reconstitutes the infrastructure, benchmarks the system under load, rewrites the parts responsible for the waste and measures again, iterating towards a net reduction of more than 15%, with every change returned as a reviewable pull request.

View full size

One run moves all eight lines in the same direction.

• Lower demand means less infrastructure and a smaller energy bill, at every instance the software runs.
• Better tested, better documented code raises fewer incidents and fewer support tickets.
• Lighter software extends the working life of the hardware it runs on, and of the codebase itself.
• Developer time released from maintenance goes back into features, which is the productivity case.
• The measurements that prove the saving are the same measurements that feed ESG disclosure and the energy rating, so compliance data arrives as a by-product of work wanted for financial reasons.

This is what makes the sustainability argument workable. Refactoring purely for efficiency is rarely approved, because it adds no visible feature and carries risk. Refactoring that is automatic, that happens inside the maintenance that was going to happen anyway, and that reduces cost on several lines at once does not need a special business case. The full financial picture is set out under lower total cost of ownership, and the measurement behind it under energy and cost reduction.

What security testing tools are to cyber security

Twenty years ago, checking software for vulnerabilities was specialist consultancy work, commissioned occasionally. Automated security testing turned it into a standing part of the build, and nobody now argues about whether to scan. Tooling of this kind is on the same path for maintenance and decarbonisation. When analysis, refactoring and measurement are automated and repeatable, keeping a codebase efficient stops being a project and becomes a habit, at a cost per run that no manual modernisation programme can approach.

What one run is worth

The climate case models this for real systems. A seven million line open-source database engine with some 47,000 deployments emits around 16,000 tonnes of CO2e a year in operation at the European grid average and carries roughly $26.5m of technical debt. Clearing that debt by hand would take about 254 developer-years. Running the pipeline instead costs a few kilograms of CO2e in AI inference and avoids about 3,700 tonnes a year. Even allowing a thousand times the modelled tokens, the carbon return in the first year is over 900 to 1.

The financial arithmetic follows the same shape. The literature reports energy savings of 10 to 30% from ordinary refactoring, and GreenCode targets more than 15% per system, measured rather than estimated. Applied to a hosting bill, a hardware refresh cycle and a maintenance budget at once, a reduction of that size is not a rounding error, and it takes effect at the moment of deployment rather than ramping up over years.