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.
Blaine is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
2
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.
5
In today’s environment, I would argue that “technical debt” is most often (a) about the developer having an inadequate understanding of the problem at hand, which they need more time to study and digest so as to solidify their understanding, or (b) about the code being in such poor condition that it fails to perform as human-readable material that the developer can put down for a while then recover understanding from later.
(a) is clearly nothing directly to do with changing the code at all, except that a better understanding may ultimately result in code previously written from a faulty understanding being changed, or future code (which may not be immediately pending) being written faster or more correctly.
(b) is to do with changing the code, but nothing about it’s quality as a computer-executable artefact, only it’s quality as documentation which is capable of reminding or reproducing developer knowledge.
Implicit in your question is the idea that “technical debt” must be concerned with “maintenance” as we know it, hence reference to Swanson’s schema of code maintenance.
But to categorise the activities above as maintenance of code, I think is like saying the function of academics is to maintain the library, as opposed to the function of the library being to maintain the capability of the academics.
The subtle difference would be apparent in cases where, for example, editing a book so that it makes more sense to the future reader (which may or may not be the author), would be characterised as “increasing the maintainability of the library”, rather than increasing the sustainability of human understanding.
Although, obviously, a more accessible library will hopefully result in academics making more and better contributions to the library in due course, it is still strange to attempt to reduce all academic activity to being a form of work upon the library.
In the conventional view, academic activity is about producing and reproducing human understanding, and a library is an auxiliary facility which academics interact with, drawing knowledge from as well as placing knowledge into.
And so it is with software development, that the primary activity is producing and reproducing the understanding of the developers who supervise the machinery.
It is therefore possible for activities regarded as “technical debt” to not be code maintenance activities at all, but activities more broadly related to producing or preserving the understanding of the developers.
In practice a lot of refactoring happens when a bug needs fixing, the cause is found, but it is inside code that is so bad you don’t dare touching it out of fear you will create a dozen new bugs.
In that situation you refactor to the point where the fix becomes easy, fix it, and make a list of problems that you found and send it to QA for checking. Don’t fix them yet.
And that is removing technical debt to enable a safe bug fix.