Free e-Book:The Modern Data Stack:A Technical Roadmap.Download for free now!
The 6 Types Of Technical Debt - Part II

The 6 Types Of Technical Debt - Part II

Series: How To Identify & Fix Your Tech Debt
Marian Pachon

Posted by Marian Pachon

on April 3, 2023 · 4 mins read

Check out the first post in this series where we explore what technical debt is, whether it's always a bad thing, and strategies to manage it and the second part of this series where we explain four types of technical debt: Decision Debt, Developer Efficiency Debt, Maintenance Debt, and Stability Debt and give real-life examples of issues and solutions for each type.

Now, let's dive back in! Technical debt takes various forms, and businesses may struggle with multiple types simultaneously. Let's explore the last two types of technical debt: #5: Security Debt and #6: Technical Product Debt

#5: Security Debt

What Is It?

Security debt occurs when shortcuts are taken, and tech teams fail to fully assess all possible outcomes leaving systems vulnerable to security threats.

Security has assumed a pivotal role. Companies must comply with regulations and actively protect sensitive data from falling into the wrong hands. Data has emerged as a new world currency, making it a target for subjects looking to take advantage of system vulnerabilities.

What Does It Look Like?

A common tell for security debt is data breaches. They occur when teams neglect to address known vulnerabilities leaving their systems exposed. Equifax, Yahoo, and Target are all real-life examples of security technical debt. Their breaches emphasize the need for timely fixes, sound security practices, configured firewalls, and secure cloud infrastructures.

The common denominator in all these cases? Millions of dollars in costs and invaluable reputational damage.

#6: Technical Product Debt

What Is It?

When it comes to technical debt, the same principle applies to the product itself - but there’s a twist. This type of debt can actually be easier to spot, since its impact is often felt directly by the end user. It’s what we call “outward-facing” debt, and its repercussions are hard to ignore. This is the debt that affects the customer experience when using the product.

But while outward-facing debt might be more noticeable, that also means it can have a big impact on your bottom line. When users experience problems or glitches with your product, it can erode trust and loyalty, leading to lost revenue and opportunities.

What Does It Look Like?

This type of debt shows up in the form of customer complaints about slow loading times or glitches in the product. We can see real-life examples of this all around us, as companies like Facebook, Amazon, and Twitter have all faced criticism in the past for technical issues. These issues often arise when companies add new features, launch products, or experience high usage during peak periods.

Paying Down Technical Debt In The Logistics Industry

Just like our last post, we’ll dive deeper into these two types of technical debt with a real-life example of a company dealing with them and some actions taken by Mutt Data to tackle said debt. Here’s a snapshot of our recent work in the Logistics industry.

Security Debt

When building a startup from scratch, development goes at the speed of light. New features are constantly being tried and tested, some are discarded while others make it into the final product (at least until there is a pivot!).

While working at this blazing speed, it’s hard to know if the systems built are robust, scalable and secure. At Mutt Data we’re used to jumping into these kinds of projects: and we have our ways to check if a system is secure. Turns out this Logistics project had multiple security issues in its codebase!

To solve this debt we had the help of Bandit that pointed out these vulnerabilities automatically, and fixed them one by one. To prevent security debt from happening ever again, we created a CI/CD pipeline that ran Bandit before each deployment: now you only get to release your code if it's truly secure!

TLDR: when building too fast it’s common to let security become a second thought. Make use of automated tools to check the security of your project to avoid these vulnerabilities before they hit production.

Technical Product Debt

This startup built an awesome logistics system from scratch in a short amount of time. But just like with Security Debt, going too fast has its drawbacks: it leaves you with little time to design an efficient and scalable system.

Design decisions made at the beginning of development were affecting both the end users (suffering from really long latency while interacting with the system) and analysts (who had to wait hours for a simple report). We realized this was happening because the same Database was being used for both end users and analysts. The initial data infrastructure built by the startup was not scalable enough for the hyper growth they had.

To solve this debt we implemented our Modern Data Stack (Read our brand new! whitepaper on the Modern Data Stack with expertly curated tool recommendations for each component). But don’t worry: it’s not like we had to build the full MDS to reap its benefits: building its first components was enough to have a huge impact on both users and analysts.

TLDR: technical debt not only affects developers, but it also affects end users. Design decisions made at the start of the project were not scalable for its hyper growth. But it’s not too late to build more appropriate systems, that with little changes can make a huge impact on the user experience.

Final Impact

  • Security is no longer a second thought: automated tools helped the client know if their project was secure.
  • Using the Modern Data Stack helped us scale their product for both analysts and end users: just building the first stage of the MDS was enough to reduce the latency of the users using the app and the analysts querying the data.

We hope you enjoyed the entire series! If you're looking for similar posts, here are some recommendations: