Technical debt is precisely what it sounds: a debt that businesses eventually have to pay with time, money, and resources, typically for choosing speed over quality. In a time where all kinds of businesses are adapting their technology and services to provide new digital channels of interactions to their customers—the “new normal”, they call it—a lot has been debated about the effects of technical debt versus business continuity.
That said, in this blog post, I hope to bring some clarity about the real impacts of technical debt and how you can manage it. Here's what I'll cover:
- What Is Technical Debt?
- Different Types of Technical Debt
- Finding the Right Balance Between Speed and Quality
- How to Manage Technical Debt
What Is Technical Debt?
Technical debt is a measure of the cost of reworking a solution, and it's caused by choosing an easy, yet limited solution, to quote my colleague Paulo Sebastião.
In other words, it’s like buying a house. You can either ask for a loan and have your dream house in the next business day, but knowing you’ll be paying interest rates for a long, long time. Or, you can wait some years, save a few bucks, and buy a house debt-free. Technical debt is for software, what interest rates are for home loans. It’s a valid solution, and it’s not problematic—until it is.
Technical debt is one of those things that’s hard to identify and to manage, and it’s also one that’s hard to avoid.
When developing, you can anticipate many things. You can spend much of your time planning your project or perfecting your code. But you can’t always plan for:
- Changes to requirements, interfaces, or functionality.
- Time-to-market pressures that may cause developers to choose the fastest, easiest approach.
- Inherited legacy systems, such as when a company is bought or merged with another.
Although we typically talk about technical debt when talking about old, legacy products, the truth is technical debt appears from day one. How many times have you been in the planning phase, looking at the list of requirements and immediately decide that you cannot meet a particular non-functional requirement in the established time frame?
You can change it later, sure. But change can make things a little messy, a little smelly too. While developing, technical debt will always find a way to sneak in, and you may introduce code smells too.
And even though your application might continue to perform most of the functions after you add a few new lines of code, it’ll hardly deliver on the expectations of the users. Just take a look at Kmart in Australia. With the lockdown in place, millions of Australians opted to do their shopping online. But the retailer’s website failed the scalability requirements, forcing Kmart to add a virtual queue—which did not go well with many of its customers.
Different Types of Technical Debt
Now, in a quest for speed, is technical debt always bad? To help me answer this question, I find it useful to use Martin Fowler’s “Technical Debt Quadrant”, where he categorized the type of technical debt based on intent and context.
With this quadrant in mind, technical debt is:
- Prudent and deliberate, when the team knows they are piling up interests, but prefer to ship and deal with the consequences later; this can happen, for example, if the interests are sufficiently small that they are not worth paying, or the payoff for an earlier release is greater than the costs of the technical debt.
- Reckless and deliberate, when the team may know about the consequences and how to avoid them, but prioritize speed over quality.
- Prudent and inadvertent, when the team learns how the solution should have been implemented after the implementation—lesson learned!
- Reckless and inadvertent, when the team doesn’t have the knowledge or experience and blindly implements the solution, without even realizing the gigantic mess they’re putting themselves into.
Anything on the left side of the quadrant is best to avoid.
Finding the Right Balance Between Speed and Quality
Software quality and performance are paramount to a good user experience—and speed is essential for reaching business goals on time. Managing technical debt requires a balance between quality and speed. Quick workarounds might mean you meet your deadlines, but make sure you are aware of the cost. Technical debt may look harmless, but if left unchecked, you’ll find that at some point, speed and agility are no longer an option.
Junior developers may lack experience and may be tempted to ignore the debt till it’s piled sky-high. Or they may find it hard to identify and fix. As organizations focus on expediting time-to-market and empowering non-professional developers (citizen developers) to create business apps themselves, the risk of technical debt increases. Citizen developers may have little knowledge of development best practices compared to professional developers.
Whatever case, there are ways to reduce and manage technical debt.
How to Manage Technical Debt
When talking about technical debt, you need to ensure the balance between time, quality, and cost, yes. But you also need to keep in mind the governance model, the toolset, and the mindset of the people that are building the software. It’s really important to get the right mix in this equation. And, although not exclusively, the right technology can also help.
Applications built with OutSystems rely on standard architectures and frameworks–no proprietary components, runtime engines, or interpreters required. With this in place, technical debt is limited before development even begins. You can learn more about it in the recent TechTalk Avoid Technical Debt for Continuous Agility.
In addition to its built-in capabilities, OutSystems recently launched the Architecture Dashboard, a tool with AI-infused capabilities designed to diagnose and manage technical debt. We’re excited to announce that it’s now available for everyone!
Use OutSystems Now!
Get your first app built in a few minutes.
It's free forever.
The Architecture Dashboard is a SaaS tool that enables developers, team leads, and architects to view and manage technical debt – by providing insights on code quality and performance so they can keep improving their apps. It offers a visual and interactive representation of the technical debt across your entire infrastructure.
Here are the main benefits you can enjoy.
1. Visualize Technical Debt
The dashboard includes a visual overview of your entire infrastructure’s debt. A heatmap chart maps out the debt, so at a glance, you can tell what’s hot (high levels of debt) and what’s not (low levels of debt). The heatmap is interactive, to drill down simply select and object to open its detailed representation or open the report.
2. Check Reports For Guidance
The streamlined interface is intuitive and easy to use. When you've found debt that caught your eye, you can drill down by opening the report. The tailored report identifies the best-practice patterns that aren't followed and also how to fix them.
“You guys don’t give us too much time to stew on our peeve points, do you? I just took a look at the latest release, and it pretty much addresses all of the concerns we had. I like the new layout, also.”
- Computershare Technology Services
3. Increase Development Proficiency
Developers can ensure their work follows best practices. You can filter the debt you added, so that you can improve the quality of your work. Fixing debt is an excellent opportunity to learn more about avoiding it in the future. After fixing your own mistakes, use your debt-fighting skills to cool down the technical debt heatmap, one step at a time.
Team leads can validate their team’s work, ensuring they deliver quality, future-proof code. Architects can oversee the entire portfolio of apps, ensuring technical debt levels are under control.
4. Avoid Code Smells
We’re always looking for ways to improve, innovate, and bring you tools that make your work better, faster, and more enjoyable. Like with anything we develop, a lot of thought has gone into building the Architecture Dashboard. We conducted hours of research, gathered and analyzed mountains of data, and talked with dozens of customers. During this time, we collaborated with Orla Dijkink.
Orla is an OutSystems consultant at LINKIT, and recently presented her master thesis ‘Occurrence of code smells in OutSystems.’ You may wonder, ‘what is a code smell?’Code smells are hard to define and depend on the developers’ experience to be identified. Code smells are hints or warning signs that there is an underlying problem with the code. With experience, developers can sniff them out, even by scanning the code, without analyzing each and every line. Smells help developers detect areas of improvement and are an invaluable tool in increasing the quality of the code. Sniffing out smells makes for better developers.
In traditional code, there is some consensus as to what are the most common code smells developers have to deal with. But what about code smells in OutSystems? That’s what Orla set out to discover. First, she identified a list of code smells. Next, Orla surveyed OutSystems developers, to learn what smells they consider to hamper the code’s maintainability. Then she correlated the code smells with bad patterns identified by Architecture Dashboard. Orla’s analysis confirmed that the bad patterns identified by Architecture Dashboard are useful for addressing the quality and maintainability of the code.
Start Fixing Your Debt Today
Experience tells us that changes become harder with time and the impact of those changes increases. Architecture Dashboard supports you as you develop by pointing out technical debt, so you can manage swiftly.
To watch the Architecture Dashboard in action, don’t miss the demo in the free webinar Avoid Technical Debt for Continuous Agility.