You have 1 article left to read this month before you need to register a free LeadDev.com account.
Estimated reading time: 6 minutes
Ever get the feeling that essential refactoring work gets deprioritized in favor of adding more product features?
You are not alone: less than 10% of IT managers actively prioritize technical debt mitigations.
Consequently, technical debt slows down developers, causing the average organization to waste 23-42% of their development time. This isn’t merely a financial issue. Poor code impacts quality of life as it introduces stressors like overtime and missed deadlines. Few people enjoy debugging a production crash in incomprehensible code. So why do organizations fail to act?
The key problem is a communication gap between engineering and business. Code quality is an abstract technical concept alien to most business managers. Consequently, code quality gets ignored at the business level and remains a hard sell for engineers. But code quality improvements can be translated into tangible business outcomes such as faster time-to-market and fewer defects.
Bridge the communication chasm
Today, refactoring is a mainstream engineering practice. However, beyond smaller improvements, large refactorings and re-designs typically need buy-in from product management.
After all, few of us can decide to ignore all feature requests for the next three weeks to clean up some code instead. Those conversations are hard since refactoring doesn’t deliver any obvious customer value – which is what product teams are typically measured against. Unlike new features, improved code quality lacks external visibility – the code does the same thing after a refactoring as it did before.
Organizations value different things. The first step is understanding what yours values most. In a hyper-growth scale-up, speed tends to triumph over everything. A predictable and sustainable development pace is likely to be more appreciated in more mature organizations. Defect reduction is a key outcome for any regulated industry. Once you have chosen the key outcome, you need to connect it to a code quality improvement. For that, we need data.
Know how code quality impacts speed and bugs
The data comes from a peer-reviewed 2022 paper by my research colleague Dr. Markus Borg and myself. Our study analyzed code quality across large enterprises, categorizing code as Green (high quality), Yellow (moderate technical debt), and Red (severe technical debt). The results reveal a stark contrast in performance:
- Speed: On average, developers complete tasks in Green code more than twice as fast as in Red code.
- Defects: Red code introduces 15 times more defects than Green code, while Yellow code comes with four times more defects.
- Uncertainty: Modifying Red code is a gamble, as tasks can take up to nine times longer compared to Green code, which has far less variation in task completion times.
Figure: Task completion times in unhealthy code are up to 9x longer compared to green, healthy code.
The differences between these three categories mean that we can turn code quality into a tangible attribute for the business:
- Speed-to-market. Healthy Green code allows you to ship features twice as quickly.
- Delivery precision: Healthy code lets you reduce the uncertainty in task completion times. You improve the delivery precision, simplifying coordination across the whole organization. Suddenly, your marketing and sales people will be able to plan their activities with greater efficiency.
- Unplanned work: A reduction in post-release defects translates into improved product maturity. Fewer defects also means fewer context switches for your team: there’s simply less unplanned work and, hopefully, fewer pages in the middle of the night.
Now that we understand the impact of code quality on development speed and defect rates, we can leverage this data to advocate for prioritizing large-scale refactoring and other code improvements.
Make the business case for code quality improvements
When you sit down to do sprint planning, that’s your opportunity to identify that one or more planned features are likely to involve unhealthy code. For instance, if you know that a new feature will involve modifying modules with Red code, you can explain that without refactoring, the feature might take twice as long to develop, with a higher likelihood of post-release issues.
At this point the team might still choose to go ahead with the planned feature. The difference, though, is that a potential delay can no longer come as a surprise. Suddenly, engineering and management have a shared situational awareness of the weak spots in the codebase.
Alternatively, the team takes this convergence of risk and relevance as a driver to refactor and mitigate the problem. Code quality improvements also now come with a business expectation. If you turn Red code Green, then that refactoring effort can come with the promises of increased development speed and defect reduction in the future.
However, code quality discussions shouldn’t be a one-off thing. To make a difference, you need to establish quality in the very DNA of the organization. That all starts with engineers. You want to monitor your code quality just like you’d supervise other vital architectural capabilities:
- Introduce a fitness function for healthy code. Measure code quality in each commit. Fail early in your build pipeline for new code which doesn’t meet your minimum standard, and fail for any code which becomes worse than it was before. (See Building Evolutionary Architectures by Neil Ford, et. al. for an introduction to fitness functions.)
- Maintain situational awareness by revisiting your code quality metrics regularly. For most teams, bringing up the latest measures once or twice a week is enough. Tie that activity to some recurring event – like Tuesday’s daily standup meeting – so that you make it a habit.
When engineers have situational awareness of quality issues, they become prepared to talk to the business supported by data.
In summary
- Measure code quality with reliable, predictive metrics. Trust is key: when you communicate with the business side, it pays off to have reliable metrics. Otherwise you might waste time fixing stuff that doesn’t need to be fixed or, worse, miss the opportunity to make an impact. Our recent benchmarking study can help in choosing your metrics and tooling.
- Identify the most valuable business outcome for your organization. Tailor your message by identifying whether speed, predictability, or defect reduction is the key priority for your organization.
- Link technical improvements to key roadmap goals. Make code quality improvements relevant by connecting them to planned work such as new features or upgrades. Aligning with the product roadmap ensures the refactoring is seen as strategic, not incidental.
- Translate the technical improvements into business outcomes. Communicate the benefits using the research findings we discussed in this article. For bonus points – and if you have access to a code visualization tool – present the code quality scores visually. That helps make them accessible to a broader audience. (See the image below for an example).
- Track and communicate the impact of code quality improvements. Show the wins by tracking key metrics over time, such as reduced bug counts, faster development cycles, and less time spent on unplanned work. Regularly share these outcomes with stakeholders to maintain visibility and support for ongoing quality initiatives.
Figure: Visualizing code quality simplifies communication: everyone can see where the strong vs weak parts are.
Treat code quality as a competitive advantage
Succeeding with software is about more than code. Efficient delivery practices, great teams, and building the right thing in the first place are all critical. Yet code quality is the foundation for all those other aspects. Companies who value code quality have a clear competitive advantage over those who don’t – it’s not just an engineering concern.
