Software maintenance and technical debt

Software maintenance, where does technical debt fit in?

Maintenance is not just about fixing bugs and implementing regulation changes, although that is where most of the effort is spent.

Under the software maintenance umbrella, according to the old but still important Lientz and Swanson study, we have four maintenance categories:

• corrective – changes in software maintenance are those that fix bugs, flaws, and defects in the software. It often comes in the form of quick, small updates on a semi-regular basis.
• adaptive – changes that focus on the infrastructure of the software. They’re made in response to new operating systems, new hardware, and new platforms to keep the program compatible.
• perfective – maintenance that addresses the functionality and usability of the software. Perfective maintenance involves changing existing product functionality by refining, deleting, or adding new features.
• preventative – maintenance that refers to software changes carried out to futureproof your product. So, software maintenance changes are preventive when they prepare for any potential changes ahead.

In the old review, over 75% of the resources allocated were spent on perfective maintenance (customer enhancements, documentation improvements, and optimizations) and adaptive maintenance (changes in hardware, software, and data).

Technical debt

We can look at technical debt as a mix of multiple categories of debt:

• code debt – affecting mostly maintainability, readability of the code;
• architectural debt – impacting the architecture of the solution;
• knowledge debt – affecting the state of documentation of the system (technical as well as functional documentation);
• test debt – affecting the quality of the applications;
• technology debt – affecting the supportability and security of the system.

After having assessed dozens of projects each year, either through the architectural assessment or the IT due diligence service that Yonder provides, I find that most software solutions have significant problems with technical debt. The specific areas include code, architectural, test and technology debt way beyond a level that I am (or the project developers are) comfortable with.

Real-world situation: debt but no resources

I can imagine that many R&D managers or VP of engineering will roll their eyes when reading this. Indeed, most developers have a desire to spend an infinite amount of time and resources on perfecting their applications’ architecture or maintainability.  Resources that, most of the time, are simply not there.

What do you do in the real world where you never have the resources needed to create the perfect debt-free technology?

Creating successful software products is hard; maintaining them is even more challenging.

Not all technical debt is equal, but often it is treated as similar. When speaking about technical debt, people think of code debt with an impact on the code’s maintainability. As such, the impression is that, well, it would be nice to have excellent implementations.

Qualifying technical debt by category

But those are not mission-critical and fall into the category of nice to have or perfective maintenance. We’ll improve things once we have dealt with the core or the critical items that were part of the tenders or contracts. Or once we have customers who are ready to escalate things.

Architectural debt is not such a clear case. There is always room for improvement, so certain parts of the architecture could be improved and, as such, fall under the same category of perfective maintenance. However, there can be systemic architectural problems in a solution that could easily fall into either corrective or preventive (like in performance or scalability problems.) Or the architectural debt can be categorized as adaptive maintenance (like preparing for a public cloud migration that could support improvements in hosting costs.)

Each debt bucket has different implications

The problem is that work done on fixing technology debt (related to keeping your third-party dependencies or platforms up to date) does not fall under perfective maintenance; it falls in the preventive or adaptive maintenance category.

By putting every type of debt into the same bucket, we neglect to deal with the different debt implications. For code debt, the impact is on development speed and quality. These are items that, in that context, can be very difficult to quantify and could, arguably, be nice to have in a context where resources are scarce.

Technology debt impacts the way you can operate your solution

Today most solutions rely on tens if not hundreds of third-party libraries and tools—all that on top of your operating system and standard development platforms.

The total security of a solution is equal to the safety of its weakest vulnerable part. With that many dependencies, you need to make sure everyone is well supported and up to date. Keeping them up to date requires effort and planning. Smaller upgrades that are backwards compatible might be straightforward to integrate and fix. But occasionally, you will have to deal with significant upgrades with compatibility problems that will require good planning and focus.

Business continuity

So, technology debt will impact your solution’s security and, together with all that is important, will fall into corrective and preventive maintenance. You don’t want to ignore this type of maintenance because it impacts your business continuity.

Security is critical because it can significantly impact your business. Imagine the impact of a ransomware attack on your SaaS solution or a supply chain attack (like the Solar Winds one) on your on-premise deployments.

Hopefully, we agree that not all debt is equal and that we could have a healthy argument over code debt or architectural debt. We should have no disputes over why technology debt should be dealt with with the utmost importance.

Remus Pereni,
CTO at Yonder

PS. I am always interested in a good discussion on software maintenance and technical debt. If you have questions or would like to share your opinion with me, please send me an email.

Would you like to find out more about technical debt? View the recording of the webinar on dealing with technical debt. Or perhaps design debt interests you?