I am trying to understand the categories of maintenance activities described by E.B. Swanson, i.e., Perfective, Adaptive, and Corrective; which category does paying down Technical Debt (TD) fall into? (E.B Swanson's Dimension of Maintenance)
I am trying to dive deep into a research-based understanding of Technical Debt. I have been looking into this, but most research that I came across seems to suggest that Paying down TD fits all three categories (The Lack of Shared Understanding of Non-Functional Requirements in Continuous Software Engineering: Accidental or Essential? , Augmenting commit classification by using fine-grained source code changes and a pre-trained deep neural language model)
The end objective is to understand which commits pay down some Technical Debt. I would appreciate it if you could also cite papers as well.
It is also possible that I am going about it incorrectly.
Edit:
The commit classification paper gives a brief outline of what the maintenance categories are:
(1) Corrective, e.g., fixing errors and faults observed during
software use, (2) Perfective, e.g., improving software quality
attributes such as performance, maintainability, usability, etc. and
(3) Adaptive, e.g., adapt the software to new environment (software,
hardware, etc.) or add new functionalities, etc. Such categorization,
supports practitioners in making decisions with respect to various
aspects such as resource allocation, choice of frameworks and
technologies, managing technical debt, etc.
Best Answer
There are many kinds of technical debt, so it isn't possible to categorize all technical debt into one maintenance category.
As alluded to in the comments, some technical debt is a failure to follow standards. This would make the work to repair that technical debt a form of corrective maintenance.
Some technical debt is about keeping your tools and dependencies up-to-date with the latest patches or on maintained versions. Sometimes, these changes may also require changes to your designs. I would classify the work needed to keep your tools and dependencies up-to-date as adaptive maintenance.
Perfective maintenance is related to maintainability. I would consider ensuring that your designs meet the current standards to fall into this category. You could make a case that some updates to tools and dependencies that improve maintainability also fall into this category.
You can fit technical debt paydown into all of the categories, depending on what the change is.
If your end goal is to examine commits and associate each one with a type of maintenance, I suggest that approach is flawed. A single commit could include multiple types of maintenance work. On top of that, some maintenance work, such as refactoring, which would likely be considered perfective maintenance, is often done in conjunction with developing new functionality, which isn't a type of maintenance at all.