The 4 types of technical debt will help you organize your perspective and how to address these deficiencies. Let’s start with a definition of the word Technical Debt.
Technical Debt is defined as deficiencies in the code, technical documentation, development environments, 3rd-party tools and development practices, which makes the code hard for the Team to change. The reality is, Technical Debt is everything that makes your code hard to work with. It’s an invisible killer of software, and must be aggressively managed.
To help Scrum Teams everywhere get a better handle on Technical Debt, we’ve identified the 4 most common types.
4 Types of Technical Debt
-
Lack of Tests
First, code that is not protected by tests is very hard to change. Developers have little or no confidence that they have successfully made a change unless they have tests proving that they didn’t break something. This lack of tests is such a big deal that Michael Feathers defined legacy code by the statement “legacy code is simply code without tests.”1
-
Bad Design
When we say bad design, we really mean code that is poorly structured in some way. There are three structural issues that we focus on:
- Once and Only Once Rule
The same behavior is not duplicated many times throughout the code base.
- Highly Modular
Each of the modules must be highly cohesive and loosely coupled to each other.
- Intention Revealing
Each of the modules should have an intention-revealing name, allowing developers to quickly grasp what the module does and why it is there.
-
Lack of Technical Documentation
In order to change code, a developer needs to be able to find the code that needs to be changed. Documentation doesn’t need to be exhaustive; it could be imbedded in the code or in a Wiki. Some sort of technical documentation is needed to make the code understandable.
-
Poor Readability
Consider that a lot of the code will be around for 5, 10, or 20 years and it will be continuously maintained and changed throughout that time. Writing Clean Code is your code’s first step in a lifelong journey. The sheer size of the code, as it grows, will make its maintenance harder and harder as time goes by. Making the code readable means it’s easier to modify or change. Here are some suggestions to improve readability:
- Another Set of Eyes
Team Members have other developers read the code it to make sure that somebody else understands it.
- Break It
Break the code into virtual modules by using comments explaining what the developer’s intent is for the next piece of code.
- Be Common
Use common, well-known, coding practices to make future developers comfortable with reading the code.
- No Secrets
Use intention-revealing names for the variables, methods, and classes to self-document.
Develop an Instinct for the 4 Types of Technical Debt
In summary, spotting these types from an outsiders perspective is extremely inefficient and error prone. The best option is to train yourself as an engineer to own and mitigate the 4 types of technical debt described here. Are there other perspectives? Sure! We are offering a pattern to help you get started on the road to professional engineering practice or improvement. It is a balance issue that a software engineer maintains as they develop, how much effort you put into mitigating or abating technical debt is the art in your practice. Technical Debt in the inevitable results of writing code. There are many steps we can take to keep our cost of change down. Here are some challenge questions you can ask yourself: What steps are you taking? What are you doing to become better? Is my team on the same page?
Having high amounts of Technical Debt is probably the number one impediment to Teams agility. Understanding the root cause of your Team’s Technical Debt is the first step towards effectively managing it. Here are 5 tips to prevent technical debt that offer another perspective.
Looking for more tools to help your Team with Technical Debt?
We’ve got training for that.
As Always, Stay Agile.
1Michael Feathers, Working Effectively with Legacy Code, Prentice Hall, 2004, pg. xvi
2“Technical Debt.” ScrumDictionary.com. Accessed Nov 19, 2020.https://scrumdictionary.com/term/technical-debt/.