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."

  • I'm not sure why someone downvoted this. It actually seems like a good question. Though it edges over into a management issue, it's still squarely within the realm of software development and software engineering. And it's a clear, well-stated question, even if I misread it the first time. – Omnifarious Nov 16 '17 at 18:03
  • 4
    One reason for the downvote might be that this concept already has at least one generally accepted name: non-functional change, which is precisely the term that the OP does not want to use. Also, I believe that "name that thing" questions are specifically off-topic here. – RibaldEddie Nov 16 '17 at 18:08
  • 4
    "Non-functional changes" is the correct term here. It coincides with Non-Functional Requirements. – Robert Harvey Nov 16 '17 at 18:21
  • I have heard that term 'non-functional changes' once or twice. I did a google search and in fact "non-functional" is a general modifier when used together with "requirement" or "testing" but not so much with "changes." Perhaps because when used with "changes" it becomes ambiguous. Nonetheless, I would be satisfied in light of the above to reword my statement to say "developers should perform regression testing when making code changes that address non-functional requirements." A bit verbose but okay... – user1527469 Nov 16 '17 at 18:23
  • 1
    Warning: you are effectively asking for suggestions outside the generally agreed definition here which makes it primarily opinion based - making it a good candidate to be closed. – Robbie Dee Nov 17 '17 at 10:12

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.

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.

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.".

  • I specifically mentioned refactoring in my question. What I'm driving at is a superset of refactoring. – user1527469 Nov 16 '17 at 17:54
  • @user1527469 - You're right, I missed that. – Omnifarious Nov 16 '17 at 17:57
  • @user1527469 - There, I changed my answer to reflect this. – Omnifarious Nov 16 '17 at 18:01
  • 'technical debt' covers code that needs to be refactored, but I haven't heard it be used in the realm of changing code that needs to be patched to address vulnerabilities. – user1527469 Nov 16 '17 at 18:11
  • 2
    @user1527469 - Vulnerabilities are bugs. Bugs are indications that your process wasn't comprehensive enough to keep them from being introduced in the first place. That means you weren't willing to pay the up-front cost for such a process and chose to incur debt instead. Which is not necessarily a bad decision, but debt ignored when the payment comes due has some really bad consequences. – Omnifarious Nov 16 '17 at 18:14

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.