Technical debt is what it sounds like: a debt that businesses eventually have to pay with time, money, and resources, typically for choosing speed over quality. In today's "new normal," companies try to adapt their technology and services to provide new digital channels of interaction to their customers. Meanwhile, many technologists debate about the effects of technical debt versus business continuity.
I talked to many companies in 2020 and heard “we need a faster go-to-market” at least as many times as I muted myself in Zoom. The truth is, applications built with a short-term mindset end up consuming a big chunk of your resources, time, and energy maintaining and rewriting “broken code” rather than developing new ideas.
But is technical debt always a bad thing? In this blog post, I hope to clarify the actual impact of tech debt and how you can manage it.
- What Is Technical Debt?
- Causes of Technical Debt
- Different Types of Technical Debt
- Finding the Right Balance Between Speed and Quality
- How to Manage and Reduce Technical Debt
- Start Fixing Your Tech Debt Today
What Is Technical Debt?
To quote my colleague Paulo Sebastião: “Technical debt is the measure of the cost of reworking a solution caused by choosing an easy, yet limited solution.”
Let's say you're going to feed a toddler some applesauce, but you realize all the clean bibs are in another room in the house. You can feed the baby sans-bib, risking the toddler covering herself with sticky applesauce, which means you need to change her now. Or, you can get the bib now, which will ultimately save you more work later. Technical debt is for software, what changing a onesie is for childcare. It's a reasonable solution, and it's not problematic until it is.
I apologize for the baby metaphor. The past 18 months have been either OutSystems or diapers. I'm working with what I got here!
The most significant consequence of a complex technical debt is that it hinders a company’s ability to compete and innovate. As Paulo Rosado once said, “The biggest cost of technical debt is the opportunity cost.” That’s because technical debt robs you of resources, time, energy, and the ability to innovate, adapt, and grow.
And it's one of those things that's hard to identify and manage and even harder to avoid.
Causes of Technical Debt
When developing a solution, you can anticipate many things and spend much of your time planning your project or perfecting your code. But there are always a few things that escape from your control, and that can lead to technical debt:
- Time pressure: Development teams often release applications that aren't full-featured or don’t have key capabilities because of pressure to deliver on an accelerated timeline. Development teams may even shortchange performance and quality to get to market quicker.
- Constant change: Even full-featured applications completed on time may arrive in the marketplace already out of date. Ever-increasing customer expectations, the rise of new market opportunities, new cyber threats, and developer turnover create ongoing challenges for IT leaders.
- Outdated technology: Developing modern applications typically involves several coding languages, developer frameworks, and libraries, which can become obsolete or not supported each year. Today's Python could be tomorrow's Visual Basic. (Sorry if you're still coding in VB...)
Although we typically talk about technical debt when talking about old, legacy products, the truth is that technical debt appears from day one. For example, have you been in the planning phase for a new project and realize you cannot meet a particular requirement in the established time frame?
You can change it later, sure. But now you are trusting that you can find the time in the future. Unfortunately, there is always another project, always another deadline. Pushing requirements out often means they never get done ever. Congratulations, you have technical debt!
A good (or bad?) example of technical debt gone wrong is thinking about the past two years. Many major retailers already had online storefronts but didn't prioritize developing them in a scalable way for many concurrent users. They did this because building it in a scalable way would have taken more time. So they pushed that requirement off in the future. At the time, this was OK because it would be implausible that their online stores would get many concurrent users at once.
Then the pandemic happened.
With many retailer's websites failing the scalability requirements, retailers needed to add digital band-aids such as adding a virtual queue. Most of those customers didn't wait and instead went to other scalable and performant online stores. Companies that took the time to build it right the first time (like Amazon, eBay, and AliExpress) enjoyed the fruits of their labor throughout 2020 while many others licked their wounds.
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 helpful to use Martin Fowler's "Technical Debt Quadrant." This quadrant categorizes 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. Still, they prefer to ship and deal with the consequences later. This decision is acceptable if the stakes are sufficiently small 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 avoid them, but still prioritizes speed over quality.
- Prudent and inadvertent, when the team learns how the solution should have been implemented after the implementation. This technical debt is a lesson learned!
- Reckless and inadvertent, when the team doesn't have the experience and blindly implements the solution. The team doesn't realize they are putting themselves into a gigantic mess.
The left side of this quadrant should be avoided at all costs.
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.
Whatever the case, there are ways to reduce and manage technical debt.
How to Manage and Reduce Technical Debt
When talking about technical debt, you need to ensure the balance between time, quality, and cost. But keep in mind the governance model, the toolset, and the mindset of the people that are building the software. It's crucial to get the right mix in this equation. And, although not exclusive, the right technology can also help.
Companies are increasingly turning to modern application development platforms to deliver unique, differentiating solutions and avoid the pitfalls of short-term solutions such as technical debt.
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.
OutSystems orchestrates the entire deployment process using a combination of automation, AI, and analytics to identify architecture errors, faulty logic, and broken dependencies—during development, in real-time.
To do so, OutSystems offers several functionalities that combined help you reduce technical debt, including:
Start Fixing Your Tech Debt Today
To learn more about reducing your tech debt from day one, take a look at Handling Technical Debt with OutSystems. This paper discusses how OutSystems helps reduce technical debt during development and assists in building a best-practices architecture to deal with it in the future efficiently.
Or visit StopTechDebt.com.
Now, if you'll excuse me, I need to grab a bib.