This step cannot be missing from any good technical debt reduction strategy, since organizations should not lose track of the already identified technical debt that they accrued. It would be just as irresponsible as taking up loans in our everyday lives and just forgetting that they ever existed. The more in detail debt can be monitored, the easier it becomes to make decisions about its management.
3.4.1
Monitored information
Some general guidelines with respect to selecting the information that is worth monitoring are detailed below:
• Technical debt items should be identifiable and it can also be bene- ficial to discover relationship between certain items. This makes communication easier.
• To further facilitate communication, the exact conditions and char- acteristics of technical debt should be described in a concise, yet clear way.
• Since the explicit type of technical debt has implications for its severity (and therefore, for its priority as well), the technical debt type should also be tracked.
• Storing the actual and up-to-date status of technical debt items in some form can be a good idea to better see the overall health of the project.
• Knowing the date of identifying a given debt item can also help to evaluate overall trends (e.g., in order to showcase the benefits of managing technical debt).
• The impact of leaving an item unattended also contributes to the success of prioritizing debt.
3.4.2
Implementation of a monitoring process
Martini et al. [28] addressed the topic of tracking technical debt in their ar- ticle. As part of their thorough study, they also identified some key elements to implementing a successful and maintainable tracking process.
First of all, they indicated the necessity of having a “champion” of tech- nical debt monitoring. This person should fulfill the role of raising awareness and advocating the adoption of monitoring practices. The “champion” can be of multiple roles: an experienced developer, a software architect or a manager, just to mention a few.
Secondly, workshops should be held, so that everybody understands the concept and goals. Forcing people to register technical debt instances without them understanding the benefits is not a viable option and it normally leads to haphazardly registered details.
Thirdly, as another resource, some time should be set aside to begin monitoring projects. For example, tools need to be configured and the exact tracking information of interest has to be specified. Although, the time spent on these steps cause a loss of productivity in the short term, they are beneficial in the long term.
Fourthly, they also highlighted the importance of guaranteeing the avail- ability of the required budget. In order to do that, it is of crucial importance to involve management people of the organization, making them understand the importance of the cause.
Lastly, the benefits of tracking debt need to be shown to the management. As it was mentioned before, it requires money and extra effort, hence, it needs to be shown that resources are not just wasted for nothing.
Li et al. [25] also addressed the topic of technical debt monitoring in their publication. They identified the below listed five approaches:
• As already mentioned before, alerts can be configured for the event of measured metrics reaching a certain threshold. When such an
alarm is triggered, the necessary technical debt reduction steps can be taken.
• Dependencies can be used to trace the propagation of the negative effects of technical debt.
• It is also a possibility to have planned checks and periodically carry out measurements.
• Another approach relies on the fact that technical debt affects qual- ity attributes of software projects. Therefore, technical debt can be also monitored by periodically evaluating attributes, such as sta- bility, reliability or flexibility.
• Identifying trends can also be a form of monitoring technical debt. However, this naturally requires having periodical measurements with a high-enough frequency, so that it makes sense to plot the data.
3.4.3
Types of monitoring tools
Martini et al. [28] also discussed what tools the participants of their survey used for technical debt monitoring. They obtained the following results, in order of prevalence:
1. Backlogs: As the most prevalent solution, participants reported the usage of backlogs. Technical debt can be tracked mixed with the items of the feature backlog or it can also have a separate backlog, exclusively for this purpose.
2. Documentation: The second most popular way according to their studies was maintaining text documents, spreadsheets or wiki pages. 3. Static analysis tools: These tools can automatically identify, mea-
sure and track technical debt. Although, there are commercial or open- source tools available (e.g., SonarQube or the CAST AIP), as reported by Martini et al. [28], some companies opt for implementing their own tools and customizing them for the metrics that they really need. 4. Issue tracking system: Creating tickets for technical debt items, just
like it is done for bugs is also an option. Normally, in these cases, par- ticipants mentioned that they assigned a low priority to these tickets, thus keeping them somewhat separated from feature-related issues.
5. Comments: This option is clearly less effective than any other in the list. As stated by Martini et al. [28], these comments usually take the form of “TODO” comments, which are convenient for developers. However, they cannot possibly form the basis of a good technical debt management strategy.