The goal of this article is to put emphasis on introducing Tech Debt identification and evaluation into development process on a daily basis. We notice that not every Tech Debt symptom makes a real debt worth to work on. There’s also addressed how Tech Debt is defined in quality expectations and how it’s correlated with Business Value.
Tech Debt definition
Tech Debt in a project or product is a state which doesn’t fulfill expected quality metrics. It reveals itself with many faces. Some of the meanings are straightforward whereas others depend on context and assumptions. In software development it means in particular:
- Not aligning to development standards and requirements set within an organization
- Having code which produces bad smells
- Referring to old frameworks versions
- Defects reported in backlog
According to Wikipedia :
Technical debt (also known as design debt or code debt) is “a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution [...]“.
Living with a debt
It’s almost impossible living without some debts. For example, when it comes to technical stuff like a brand new laptop or a car, these products bought today, will be face lifted, or replaced by newer versions sooner or later. It’s up to the owner if they cause a debt to him/her. Let’s consider this. Do you have a debt in automotive area if you’re driving an old-timer car? Probably not. What about driving 15 years old compact car? It may rise a feeling of a debt. We conclude here that a debt is a relative term. Tech Debt in software development is relative too. See The TIOBE Programming Community index  which is an indicator of the popularity of programming languages. The ranking has been showing for a long time C language in a very high position. On the other side, isn’t C an old language? It appears to be since it’s been available from late 70s. Is it a Tech Debt to write a program in C? Not necessarily. Writing a new module in C for an old account managing system might be considered as increasing TD. It’s because the solution written in newer languages, frameworks and architectures would make it up to date with nowadays standards. That written in C is far away of them, and the distance is getting longer. From another point of view, assuming the base solution is properly developed in C and has no business need to be rewritten in Java or Scala. The module written recently in C follows all requirements and clean code. Where is a debt here?
Tech Debt vs. Business Value
In agile project management there are three factors influencing the final product. They come in the following order: Value, Quality and Constraints, see The Agile Triangle . TD is a part of (poor) quality.
Who is responsible for producing, identifying and reducing Tech Debt? As long as quality is a significant part of the product in the agile process, Project Manager or Product Owner accepts Tech Debt. Tech Debt is a subject of discussions and actions with many trade-offs on the way. It’s not always sensible to fight with the whole debt. Consider already developed module which is completely non-maintainable and non-extensible. However, it works fast and properly. No further modifications are required. The module brings a debt but resolving it doesn’t bring value. Every potential debt item has to be evaluated aligning with Business Value.
There is no Business Value in resolving Tech Debt. Some people say so. They see the debt is about how the code looks like not necessarily how it works from user point of view. The code is no longer needed, right? If so, let’s drop the code and start working only with binary/bytecode versions. Tech Debt in implementation is resolved then. TD prevents product from maintainability and extensibility. If you accept it, resolving such a debt is worthless.
TD in terms of its classification has a certain value. TD can be also considered taking into account the Business Value. Even though the debt in code is high, the impact on BV doesn’t have to follow this. This is a comparable case to Story Points and Value Points  for User Stories.
Evolutionary Tech Debt
Agile environment requires continuous inspection and adaptation. Tech Debt is a relative term and exists in the agile environment. It implies that Tech Debt should be a subject of continuous inspection and adaptation as well.
Handling Tech Debt is an evolutionary process including:
- Identifying Tech Debt items
- Managing these items (evaluating, reporting, planning, resolving)
- Managing them as tasks in issue tracking system
- Aligning solution to current requirements and rules
Common working agreements on Tech Debt
TD has to be drawn in a picture commonly understood by all TD’s stakeholders. It has to cover all artifacts and actions to be taken. That’s some kind of DoD known from Scrum.
- Identified Technical Debt issue is created as a Task in issue tracking system
- The task is properly described.
- The task has appropriate keyword, e.g.: tech_debt
- It may have links to other items in backlog
- It may be classified for certain type of debt as a label in the task
- As a regular task it may be decomposed to smaller parts
- Planning these items on sprint planning/backlog refinements
- Resolving the issues
- Tracking Tech Debt (e.g. items reported vs. resolved)
Accept Tech Debt as it comes and make the product better. Develop a plan and common working agreements for a team and organization to have the debt in control. Not every code deviation has to be classified as a debt. Call and resolve Tech Debt only what makes a real debt in a given context.