Solve the drag of technical debt with application stability
Do you ever get mad at your code base because you can’t accomplish something?
That, my friends, is what we call the emotional side of technical debt. Simply put, technical debt is anything that slows down the creation or maintenance of new product work inside a code base.
Because it develops over time, technical debt often comes from three sources: fast coding for speed-to-market; continued reliance on older systems with exposed flaws; and incremental changes to a code base that adds complexity and degrades the original system design.
To be clear, everyone has technical debt. It’s a fact of life in software development.
Technical debt is also a one-way road to lost productivity and increasing levels of frustration. These two factors have a rather unfortunate emotional “drag” on engineers. Because technical debt is considered an “engineering problem,” team members may find it hard to explain its criticality to those who are, shall we say, less technical-minded.
Making matters worse, there are always competing product and business interests. Scheduling development time for what’s viewed as “refactoring” will almost always lose out to building new features and pleasing customers, which are money-making activities.
Wouldn’t it be great if your engineering, application, and product teams could agree upon the impact of technical debt and talk about it openly and regularly?
Well, now they can. But first, everyone must find shared and stable ground.
How to align around technical debt
Whenever you rely on older code bases or release code quickly, you ship with bugs. While engineering teams may strive for zero bugs (which isn’t necessary, by the way), product teams often don’t mind a few bugs because they are focused on enhancing the overall customer experience.
This disconnect in expectations leads to a pretty sizable chasm between the two teams, which is then exacerbated when the topic of technical debt comes up. Developers will argue that they need to address underlying problems in the code base, while product will focus on building new features to please customers.
Neither team is right or wrong. Each is simply doing its job. What’s missing here is alignment and the two factors needed to achieve it:
- A common language to discuss technical debt, and
- A method to measure the impact of technical debt.
Measure technical debt with the stability score
Thankfully, we can look to infrastructure and operational teams for inspiration. The “five nines” they use to track availability, measure uptime, and conform to SLAs is the same concept that can be applied to technical debt. How so?
By adopting a stability score that measures how stable a software release is.
Stability scores are calculated with real-time error rates and session data to determine the percentage of successful user interactions per release. By focusing on how many customer interactions are crash-free and how many bugs are deemed “too many,” stability scores become a new first-point of entry to answer questions like:
- What is my target stability?
- Is my stability score above my target for each release?
- If my stability score is below my target, which bugs should I fix first?
- Do I fix bugs that affect a key customer or those that impact many customers?
Stability scores provide insight into the actual impact of your technical debt. If you know with certainty that the proverbial camel’s back will break if another straw is put on it, then everyone can agree that the time has come to pay the piper and address technical debt.
How do teams get stability scores? By adopting a stability management and error monitoring tool like Bugsnag, which metricizes and analyzes stability. By being metrics-driven and speaking in a common language, you get a single answer to the age-old (and historically divisive) question: Do we fix bugs or build new features?
Upside generation over downside protection
Engineering teams may face a cultural challenge with technical debt as well—and it’s usually within their own team. After being told repeatedly that there’s no time in the development schedule for addressing technical debt, long-term engineers can become complacent about it. When new team members join and attempt to address technical debt, they may be told, “That’s just the way it is.” Pretty much what everyone wants to hear, right?
Understandably, this attitude leads to frustration and disengagement. Without addressing the emotional drag of technical debt, companies risk losing great people and creating a culture that stifles creativity (not to mention slowing down development and innovation).
That all changes with stability scores. Engineering teams can point to a release with a low stability score and turn it into a measurable example that shows the impact of technical debt through bugs and revenue hits (crashes, lost customers).
Needless to say, this translation of technical debt into business value is game changing. Suddenly, product and business owners understand why a real need exists to address technical debt. Eureka!
The question is never “if” but “when” with technical debt. And it’s much easier to gain consensus when you have a metric that provides insights into release stability and concrete reasons to take action.
Stability as a measurable KPI
Want happy customers? Then you absolutely must have a stable user experience. This is a non-negotiable. Consumers are fickle and will switch apps if you crash (80% will only retry an application once or twice), and approximately four out of ten will think less of your brand. And we all know how important positive word-of-mouth is in a hypercompetitive app world.
These consumer realities point to why companies are adopting stability as a KPI. It’s no longer feasible to separate business metrics from software stability. And, hey, that’s great news for developers. It means technical debt can be rolled into the engineering team’s goals through the stability score.
By adopting a stability management tool like Bugsnag, developers can have a voice in the room, and stability becomes the business-impacting metric that everyone shares.
And that’s definitely not something we’d call a “drag.”
