The cost nobody itemises

View full size

Software quality is tightly coupled to operational performance, as the ISO/IEC 25010 quality model sets out, and short delivery cycles keep introducing the defects that break that coupling. The consequences are well documented in four decades of completed project data and in the green software engineering literature. They rarely appear together on one page, because each lands in a different budget.

Sub-optimal software costs an organisation:

• More hardware, more infrastructure and more energy to run 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 them.
• Inconsistent implementations of the same thing, each of which has to be understood separately.
• Safety and security exposure, in systems where a defect is not merely 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 line of the finance system is labelled "inefficient software", which is precisely why the total is rarely challenged.

What the numbers look like

View full size

Technical debt has been estimated at about $3.61 per line of code. On a system of a million lines that is roughly $3.61m of deferred cost carried on the books without ever being recognised as such.

Clearing it by hand is expensive. 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%. Published estimates put manual refactoring at 3 to 5 EUR per line or more. Between 60 and 80% of all software in service is legacy, so this is the normal case rather than the exceptional one.

Hosting is the other half of the picture. Cloud and data centre charges are treated as a necessary cost of doing business, reviewed for discounts rather than for cause. The demand that sets them comes from the software, and the software is treated as a black box.

How GreenCode attacks every cost line at once

GreenCode automates the three steps that an organisation would otherwise pay people to perform. It baselines the codebase and its infrastructure, measuring quality, performance and energy under load. It refactors, using specialised generative AI, generating the tests and documentation the code was missing as it goes. It then optimises for energy and measures again, iterating towards a target of at least 15% net reduction, with every change returned as a reviewable pull request.

Because the work happens in one pass, the savings arrive together. Lower demand means less infrastructure and a smaller energy bill. Better tested, better documented code means fewer incidents and fewer support tickets. Lighter software extends the working life of both the hardware and the codebase itself. Developer time released from maintenance goes back into features, which is the productivity case.

Crucially, the effort does not have to be justified on sustainability grounds alone. Refactoring purely for efficiency is rarely approved. Refactoring that is automatic, that runs inside routine maintenance, and that reduces cost across several lines at once does not need a special business case.

What security testing tools are to cyber security

Twenty years ago, checking software for vulnerabilities was specialist consultancy work, commissioned occasionally and priced accordingly. Automated security testing turned it into a standing part of the build. Nobody now argues about whether to scan.

Tooling of this kind is on the same path for software maintenance and decarbonisation. When the analysis, the refactoring and the measurement are automated and repeatable, keeping a codebase efficient stops being a project and becomes a habit, at a cost per run that bears no resemblance to a manual modernisation programme.

Compliance paid for by the same run

The run that lowers cost also produces the evidence. The measurements behind the savings are the same measurements that feed ESG data and the rating behind certified energy efficiency. An organisation that would have paid separately for a sustainability assessment gets one as a by-product of work it wanted for financial reasons, so the cost of compliance falls alongside the cost of ownership.

Sustainable growth, not only lower bills

This is where GreenCode contributes to Sustainable Development Goal 8, on decent work and economic growth. Lower total cost of ownership protects margin, and decoupling business growth from hardware and energy consumption is the substance of that goal. Removing mundane maintenance work from skilled developers, in a sector with a persistent skills shortage, is the other half of it.

Where GreenCode is working on this

Automated quality baselining, static analysis and artefact generation sit in the static code analysis work package. Infrastructure discovery and energy monitoring sit in the green DevOps and infrastructure assessment work package. The optimisation loop, benchmarking and the reporting that turns a run into figures a finance lead can use sit in the processing pipeline and benchmarking work package.

Organisations that want to trial the tools on their own codebase, or contribute a use case, can reach the consortium through the contact page.