.png){kind=small}
Over the years, I’ve worked with organizations like Boeing, the Pentagon, and Amadeus to build ROI-based cases for technical health investments. Whether it’s refactoring to improve architecture health, addressing code duplication, or increasing test coverage, the challenge is always the same: convincing a CFO that these technical initiatives are worth the investment.
CFOs tend to prioritize features and bug fixes because their business value is clear—features drive revenue, and bug fixes protect reputation. But technical health often gets dismissed as a cost with no market demand. As one CFO bluntly put it to a colleague: “Go pound sand.”
But here’s the thing: presenting technical health in the wrong terms can make things worse. I once heard a developer try to explain technical health to a financially oriented decision-maker by saying the codebase had “code smells.”
For those unfamiliar, “code smells” is a term coined by Kent Beck and popularized by Martin Fowler in their work on Refactoring: Improving the Design of Existing Code. It refers to structural issues in code that might indicate deeper problems—for example, excessive duplication, overly long methods, or unclear naming conventions. While not always bugs themselves, code smells suggest areas of code that are harder to understand, maintain, or extend.
The developer in this story, however, didn’t explain this properly. The decision-maker, baffled, responded: “Are you telling me your code is smelly?” The meeting ended shortly after.
That exchange stuck with me as a cautionary tale. Developers and technical leaders need to speak the language of business—not just because it’s more effective, but because failing to do so can actively harm their credibility.
Fortunately, I’ve seen the opposite happen too. When developers and architects translate technical issues into business outcomes, they can completely change how technical health is perceived. One of the best examples comes from my work with Martin Jouvenot at Amadeus. Here’s how he turned technical health from “go pound sand” to “tell me more” in six steps.
Martin Jouvenot, an architect at Amadeus, faced a similar challenge. Together, we modeled the value of improving test coverage in one of his systems, and Martin turned the results into a compelling business case. He didn’t just focus on the technical improvements; he framed the initiative in financial terms, using the same language as Lean, Six Sigma, and business process improvement professionals.
Martin and I shared this approach in a webinar at MIT to help others understand how to make a business case for technical health investments. You can watch the full webinar here:
Here’s how we did it, in six steps that you can follow to go from “go pound sand” to “tell me more.”
Step 1: Start with a Hypothetical Proposal
Martin kicked off the conversation with a clear and plausible proposal:
Proposal: “Let’s improve test coverage across the codebase to a minimum of 90%.”
Rationale: “Higher test coverage will allow us to catch bugs earlier, preventing costly downstream fixes. Right now, some files have 0% coverage, some have 100%, and most are in between. Raising the standard to 90% will reduce long-term costs and improve software quality.”
He framed the problem in business terms to resonate with the CFO:
“We’re spending significant time (and money) fixing bugs that could’ve been prevented. Writing tests now will cost less than fixing bugs later.”
This approach isn’t limited to test coverage. When I worked with Boeing and the Pentagon, similar proposals were made to improve modularity, reduce duplication, or eliminate architectural cores—always focusing on how these improvements reduce costs, accelerate delivery, and mitigate risks.
Step 2: Collect Data and Build a Statistical Model
To back up the proposal with data, we built a statistical model linking technical health metrics to business outcomes. Amadeus had a wealth of data from its systems:
Source Code: Test coverage and complexity metrics.
Version Control (e.g., Git): Change frequency, churn, and author activity.
Issue Tracking (e.g., Jira): Defect counts, resolution times, and bug types.
We combined these inputs to predict file-level defect counts based on test coverage and other factors like file size and complexity. The results showed a clear correlation:
Files with low test coverage (<50%) had 3x the defect rate of files with high coverage (>90%).
This kind of model isn’t just theoretical—it’s been used successfully with other organizations, from aerospace to defense, to quantify the costs of poor architecture and technical health.
Step 3: Simulate the Current System
Using the model, Martin simulated the predicted defect count for his current system. He input the actual test coverage values, file complexities, and other metrics to calculate the baseline defect load for the codebase.
This step validated the model but wasn’t part of the CFO pitch. Instead, it served as a foundation for the next step, where the CFO really started paying attention.
Step 4: Simulate the Hypothetical Improved System
Here’s where things got exciting. Martin simulated the system under a hypothetical future state—one where all files had 90%+ test coverage. By comparing this improved state to the current one, he calculated the defect reduction:
Current Defect Count: 2,000 defects/year.
Hypothetical Defect Count: 1,000 defects/year.
Defect Reduction: 1,000 fewer bugs annually.
For similar efforts, like reducing architectural cores or improving modularity, we’ve seen comparable defect reductions, which translate into massive cost savings and productivity gains.
Step 5: Estimate the Annual Savings
With the defect reduction quantified, Martin translated it into financial terms:
Time Saved: Each bug takes 4 days to diagnose, fix, and test. Reducing 1,000 defects saves 4,000 days/year.
FTE Savings: At 200 workdays per year, that’s 20 FTEs saved annually.
Cost Savings: With developers costing $100,000/year, the annual savings totaled $2M.
The breakeven point for the $1M investment in improving test coverage was just 6 months.
Step 6: Calculate the ROI
Finally, Martin presented the ROI in terms the CFO could respect. Using a 5-year time horizon and a 10% discount rate:
Present Value of Savings: $3.79M.
ROI:
Martin delivered it simply:
“Invest $1M to achieve $3.79M in savings, for an ROI of 279%. The initiative pays for itself in just 6 months.”
From “Go Pound Sand” to “Tell Me More”
Martin’s case worked because it wasn’t just about test coverage—it was about business value. By using a statistical model, he quantified the costs of inaction and the benefits of improvement, framing technical health in terms any Lean, Six Sigma, or business process improvement professional could appreciate.
This is the lesson: Whether you’re explaining “code smells,” test coverage, or architectural refactoring, the key is to connect technical improvements to business outcomes. Otherwise, you risk the CFO responding with, “Are you telling me your code is smelly?”
Want to transform how your organization thinks about technical health? Let’s talk!
Comments