Understanding Tech Debt

This content originally appeared on DEV Community and was authored by Clifford Otieno

• Understanding Tech Debt
  • What is Tech Debt in Software Development?
  • What is Tech Debt in Agile and Scrum?
  • Common Examples of Tech Debt
  • Code-Level Debt
  • Database Debt
  • Architecture and Infrastructure Debt
  • Conclusion

What is Tech Debt in Software Development?

Think of technical debt (or tech debt) as taking a shortcut when writing code. You choose a quick and easy solution for now, knowing that you’ll have to come back and fix it properly later. It’s like borrowing money. You get something now, but you have to pay it back later, and often with “interest.” This “interest” means that making changes to your software in the future will be slower and more difficult because of the shortcut you took.

What is Tech Debt in Agile and Scrum?

In agile development, where the goal is to release software in short cycles (sprints), teams can easily create tech debt. The pressure to finish work within a sprint might lead them to cut corners.

Here are some things to watch out for in agile:

• Meeting Deadlines: Rushing to meet a sprint deadline can lead to messy code.
• Changing Plans: When project needs change, the old code might not be a good fit anymore.
• What “Done” Means: A good team agrees on what it means for work to be truly “done.” This should include writing clean code.
• Making it a Task: The best way to handle tech debt is to add it as a task in the project plan. This way, it doesn’t get forgotten.

Common Examples of Tech Debt

Tech debt can show up in many ways. Here are a few common examples:

Code-Level Debt

• No Instructions: Code without comments or documentation is hard for others (or your future self) to understand.
• Not Enough Testing: Without good tests, fixing one thing can accidentally break something else.
• Copy-Pasting Code: Writing the same code in multiple places instead of making one version that can be reused.
• Mysterious Numbers: Using numbers in code without explaining what they are for.

Database Debt

• Poor Normalization: Storing the same piece of information in multiple places. For example, having a customer’s address stored with every order they make instead of in a separate customer table. This makes updates difficult and can lead to inconsistent data.
• Inconsistent Naming: Using different names for the same kind of data in different tables (e.g., CustomerID in one table and Cust_ID in another). This makes writing queries confusing and error-prone.
• Missing Indexes: A database index helps find data quickly. Without a proper index, the database has to search through every row to find what it’s looking for, which can be very slow, especially with large amounts of data.
• Ignoring Data Types: Storing data in a generic type (like a text field) when a more specific type (like a date or number) would be better. This can lead to bad data and makes it harder to work with.

Architecture and Infrastructure Debt

• Tightly Coupled Components: Creating parts of the system that are so dependent on each other that changing one part requires changing many others.
• Outdated Dependencies: Using old libraries or frameworks with known security holes or performance issues.
• Lack of Automation: Manually deploying code or running tests when these processes could be automated. This is slower and increases the chance of human error.

Conclusion

Tech debt happens in almost every software project. Sometimes, taking shortcuts is necessary to get things done quickly. But it’s important to keep track of these shortcuts and plan to fix them. If you don’t, your software will become hard to work with over time. The best approach is to deal with tech debt regularly to keep your code clean and easy to maintain.

This content originally appeared on DEV Community and was authored by Clifford Otieno