on April 03, 2023 · 3 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
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.
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.
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.
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.
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.
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.
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.
We hope you enjoyed the entire series! If you’re looking for similar posts, here are some recommendations:
