Ensuring Mastery Over Functional and Technical Debt
First, let's understand what we mean by:
Functional Debt occurs when an application has partially designed or invisible features that clutter the code.
Technical Debt arises when the speed of a project takes precedence over quality, necessitating additional downstream correction work. It also occurs when developers are unaware of best development practices, such as in the case of a junior developer.
Functional Debt
Functional debt arises when we have partially designed features or do not meet user needs. This results from design choices, like delivering basic functionalities or technical features that are no longer used (obsolete tables, dead code, etc.).
How Can We Measure This Debt?
Unlike Technical Debt, there are no straightforward tools to measure Functional Debt. However, advanced tools like Code Scene or CAST can help detect this debt based on assumptions like:
- Code that is never touched could potentially be dead, but not necessarily.
- Code sections never called or tables never visited might be dead.
- Using these tools can provide insights, but discussions with application developers are also essential to understanding the utility of each component, class, and table.
Ultimately, for each discovery, we should create a correction task, for example, with a Functional Debt label, and insert it into the Backlog for future correction.
Functional debt due to unimplemented or partial features:
- This situation typically exists in projects where feature delivery is measured against value delivery, with undelivered features of low value.
- When a User Story is partially implemented, create a new user story for the unimplemented part, linking it to the complete User Story.
- When committing your US in GIT, the message should contain the ticket number.
- Any US unfinished project delivery is considered functional debt.
Functional debt due to dead code:
- Use GIT introspection tools like Code Scene or CAST.
- Monitor your application with tools like Dynatrace to identify unused parts of your application.
- Consider bringing in a software modernization expert to help refactor your code for better content mastery.
- Document in your issue tracker with the issue type: Functional Debt for debts identified but not corrected.
Code Scene
Technical Debt
Technical Debt occurs when choices, either deliberate or not, are made to deliver a project quickly, pushing corrections to later.
Steve McConnell, Chief Software Engineer at Construx Software, identified two types of technical debt:
- Voluntary (Type II): This is when an organization deliberately decides to optimize the present over the future.
- Involuntary (Type I): This is considered accidental, often due to poor design choices, and is usually realized during updates or adding new values.
When choosing measures to take, we consider two categories of debt:
- Long-term Debt (Type II.B): Debt that can wait and will be corrected later or perhaps never.
- Short-term Debt (Type II.A): Debt that will be corrected in the short term, as it is important to the team, such as tactically interesting topics like updating a framework version.
- Targeted Short-term Debt (Type II.A.1): Shortcuts taken in the application design, like delivering without the latest framework version.
- Non-targeted Short-term Debt (Type II.A.2): Deliberate non-adherence to OO programming rules, identifiable by code smells.
Depending on the type of debt we are addressing, different measures can be implemented to track it. We do not differentiate between Type I and Type II debt.
Targeted Short-term Debt:
- The team sets up a table with its application framework versions and tracks them monthly. Note that some frameworks, like Angular or Java, have version changes every six months. For Angular, not following these versions can significantly impact, less so with Java. Create a "Technical Debt" ticket with the details of the framework update.
| App 1 | Spring | 2.5 | 6.13 |  | Travail de mise à jour important version plus supporté risk sécurité élevé |
| App 2 | Framework .Net | 4.8 | 7.2 | | Travail de mise à jour important version plus supporté risk sécurité élevé |
| App 3 | Angular | 10 | 11 |  | Travail mineur de mise à jour < 6 mois |
Non-targeted Short-term Debt:
- A good practice is to inspect Sonar results and spend 15-30 minutes each day cleaning up code smells, for example.
Annexe
