Back

What It Is and Why You Should Care

Understanding Technical Debt

2024.05.31

Picture this scenario: a successful B2B company in Hong Kong is presented with a fantastic opportunity to digitally transform its operations, promising substantial profits. However, to capitalize on this opportunity, they must invest a significant portion of these potential profits into fixing their current technical infrastructure. Why? Over the years, their tech stack has become increasingly complex due to numerous “quick fixes” made for faster delivery. This situation perfectly illustrates the concept of technical debt.

What is Technical Debt?

Technical debt, often referred to as tech debt or code debt, is the cost of additional rework caused by choosing a quick, short-term solution over a more thorough, long-term approach. The term was coined by Ward Cunningham in 1992, comparing these technical shortcuts to financial debt that must be paid back with interest later.

Why Should You Care About Technical Debt?

  1. Slows Down Innovation: As technical debt grows, it holds back your team’s ability to innovate and roll out new features. Instead of developing new solutions, developers are bogged down fixing existing issues.
  2. Increases Costs: Over time, the cost of maintaining and updating your systems can skyrocket. What seemed like a quick fix initially can turn into a significant financial burden.
  3. Reduces Quality: Technical debt often leads to poorer code quality. While quick fixes may solve immediate problems, they can introduce bugs, vulnerabilities, and inefficiencies that degrade the system’s overall performance.
  4. Restrains Scalability: For organizations aiming to scale their cloud-native solutions, technical debt can be a major obstacle. Systems weighed down by technical debt struggle to handle increased loads and new requirements.

Types of Technical Debt

Technical debt can be categorized into two main types: intentional and unintentional debt.

  1. Intentional Technical Debt: This type of debt is incurred knowingly when a less-than-optimal solution is chosen due to constraints like limited resources, business demands, or tight deadlines. These decisions are often strategic, made by both business and tech teams, and come with plans for future remediation.
  2. Unintentional Technical Debt: This type arises from mistakes, lack of knowledge, or inadequate planning. It can result from inexperience, poor practices, or technological changes that make previous solutions obsolete. Unintentional debt is harder to track and often only becomes apparent when it starts causing problems.

The Technical Debt Quadrant

Martin Fowler, a renowned software engineer, expanded on the concept of technical debt by introducing the Technical Debt Quadrant. This framework helps organizations categorize and manage their technical debt more effectively. The quadrant divides technical debt into four types based on whether it is prudent or reckless, and whether it is deliberate or inadvertent.

Technical Debt Quadrant by Martin Fowler
Technical Debt Quadrant by Martin Fowler
  1. Prudent + Deliberate: This is when a conscious decision is made to release a quick fix with full awareness of the consequences. The team plans to address the issues later, believing the benefits of quick delivery outweigh the debt.
  2. Prudent + Inadvertent: This occurs when issues are unknown before the release. The team accepts that a better solution can be implemented in the future once the problems become apparent.
  3. Reckless + Inadvertent: This type of debt is typically due to lack of experience or knowledge. The team is unaware of the mistakes being made until problems arise.
  4. Reckless + Deliberate: Here, the team knows the best practices but intentionally chooses to ignore them for the sake of speed, fully aware of the negative consequences.

13 Types of Technical Debt

Academics have identified 13 distinct types of technical debt, each affecting different aspects of software development and maintenance. These types are outlined in the paper “Towards an Ontology of Terms of Technical Debt”. Here are the categories:

  1. Architecture Debt: Flaws or shortcuts in the overall system design.
  2. Build Debt: Inefficiencies or problems in the build process.
  3. Code Debt: Poor code quality or lack of adherence to coding standards.
  4. Defect Debt: Accumulated bugs and errors that need fixing.
  5. Design Debt: Suboptimal design decisions impacting usability and maintainability.
  6. Documentation Debt: Inadequate or outdated documentation.
  7. Infrastructure Debt: Issues within the underlying hardware and software infrastructure.
  8. People Debt: Skills and knowledge gaps within the team.
  9. Process Debt: Inefficient or poorly defined development processes.
  10. Requirement Debt: Unclear or evolving requirements that were not properly addressed.
  11. Service Debt: Problems within service-oriented architectures or APIs.
  12. Test Automation Debt: Lack of or inadequate automated testing.
  13. Test Debt: Incomplete or missing tests for code.

Understanding these types can help organizations identify and prioritize their technical debt, ensuring more effective management and resolution.

Can Technical Debt be Reduced, or Paid Off?

Technical debt is an unavoidable aspect of software development, especially in the fast-paced cloud-native solutions. However, understanding its impact and actively managing it can help organizations in Hong Kong stay competitive in their DevOps journey. By addressing technical debt, you ensure your systems remain robust, scalable, and cost-effective in the long run.

In our following posts, we will explore the key components that make up a successful platform engineering strategy in order to “pay off” your technical debts.