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 realized 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 and you end up with technical debt.
Technical Debt Example
An 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 retailers' websites failing the scalability requirements, retailers needed to add digital band-aids such as 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 answer this question, it’s 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.
- 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 know 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 technologies, like low-code development platforms to deliver unique, differentiating solutions and avoid the pitfalls of short-term solutions such as technical debt.
That’s the case with OutSystems.
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:
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.