Term for changes that do not include changes to product functionality

Question

What is a good term to use for when I want to describe changes to the codebase that does not involve changing or adding functionality. This would include bug fixes, security patching -- including library upgrades, and perhaps refactoring as well.

The term would replace the incorrect sounding "non-functional changes" in the sentence below:

"Developers should test for regressions when committing non-functional changes to the code-base"

What is the best way to phrase the above statement, ignoring for a minute the meaning of the statement itself and all the things that are wrong with it.

The term would also apply when discussing stories that do not provide direct business value and therefore are a harder "sell" during sprint planning. I.e. they can not be framed with the story template "As a user, I would like to do X."

Therefore the term is a bucket term for work planned that is not tied directly or even indirectly to new features or enhancements. I was thinking of using something like "extra-functional" or something like that to avoid the roundabout "changes to the code base that are not directly testable apart from comprehensive regression testing."

Answer 1

I might be tempted to call these things 'regular/preventive maintenance'. I have explained something similar to my managers before and related it to car maintenance.

That security update? It's like changing the oil in your car, it costs a small amount now, rather than a giant amount in the future when you would otherwise have to pay for a new engine that's seized or all your customers data is stolen because you could not be bothered to update a known vulnerability.

That library update? It's like getting new tires. Just like tire technology has gotten better over the years and you would not chose to drive around on tires from 1973, that library from 2 years ago might no longer be the top dog.

Refactoring? It's like cleaning out your trunk. You know one day your client asks for a new feature and you will think to yourself it would have been much easier to implement 6 months ago if you had just thrown out the old Cheetos bags in the back back then rather than pile a bunch of bags of cat litter on top of them.

(Ok, I think I might have taken that last one a too out there)

None of these things turn your car into a new Ferrari, but it keeps it from turning into a rusted out Form Pinto.

Answer 2

It seems you're trying to sell to management, the concepts of maintenance and technical debt. I was surprised the word "maintenance" didn't come once in your question. And that's why I think it's the answer!

From the very definition of maintenance from Wikipedia...

Software maintenance in software engineering is the modification of a software product after delivery to correct faults, to improve performance or other attributes.

As a term in your sample sentence I think these two would fit:

Technical / Functional Enhancements I would argue not to call it just "Technical Debt" as this is debt + refactoring + security + performance. Enhancements don't mean adding something new necessarily, rather "enhancing" the existing product.

Maintenance Patch

I've heard this quite a lot from big products' update announcements. They never bring new features and there's almost no noticable changes for the Users.

Answer 3

I would call these changes "technical debt payments". That gives them the gravity they deserve. They are changes you need to make now to avoid even worse problems in the future. No, they don't get you anything new or shiny. You've already gotten the new and shiny thing, and in the course of doing it have incurred technical debt.

This will also encourage managers to think about ways to avoid incurring the technical debt in the first place. Adopting practices that reduce the number of bugs (an important subset of which are security issues) that make it into production will then seem like a much better idea.

I guess then that the sentence you give would be "When engaging in changes that are technical debt payments, developers should run regression tests to avoid incurring more technical debt in the process.".