What is an antonym for "refactoring" with regards to programming?

Question

Consider this definition of "refactoring" from Martin Fowler's book, Refactoring: Improving the Design of Existing Code:

Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure.

What is an antonym for this definition of refactoring? More specifically, how would one describe the process of worsening or deteriorating the internal structure of a software system?

Someone pointed out that refactoring is an intentional act, and that there probably isn't a word that describes intentionally making software worse. I am fine with an antonym that does not communicate intention.

Answer 1

The idea that software degrades over time is known as software rot (or, slightly less specifically, "bit rot"). There are two main variations. The first is that software that is not being maintained gradually degrades over time as the environment around the software changes. For example, upgrading to a new version of an operating system might make an existing software package stop working.

However, I think you are referring to the second variation, active rot (sometimes referred to as "software entropy"). In this variation, changes to the software increase the complexity of the software and degrade its internal structure. Programmers sometimes refer to these kinds of changes as technical debt, especially when making changes that are expedient in the short term, but that you know -- even as you are making the change -- that you will need to pay for later.

Answer 2

Refuctoring

The process of taking a well-designed piece of code and, through a series of small, reversible changes, making it completely unmaintainable by anyone except yourself.

Bit tongue in cheek, but as you mentioned in the original post, people don't (normally) intentionally make code worse!

Answer 3

If we want a well-known word that appears in standard dictionaries, and already has a domain-specific definition which applies specifically to software, I would recommend you use obfuscating, which is defined in the software discipline as something like "the process of making code harder for humans to understand." This can be done simply by removing relevant comments, or by using 'hacks' (anti-patterns), or by exploiting numerous language gotchas.

Obfuscation is often applied to low-level languages to make machine-code harder to reverse-engineer, but it can also be done on higher-level code, often to secure someone's hegemony over a given section of code by making it unpleasant for other programmers to deal with, even if it is open-source or otherwise shared amongst a group of people.

Answer 4

Technically, Martin Fowler's definition of re-factoring is overly-specific. Re-factoring refers to changing the internal structure of a piece of software without affecting its visible behavior, regardless of whether the change is an improvement (which is subjective anyway). He gives the definition has he does for two reasons:

• Most changes that degrade the quality of a piece of software's design also affect the visible behavior (are side-effects of feature changes), so there isn't much call for a word to describe internal-only changes that make software worse.

• It's not always clear (especially to software managers!) why someone would want to engage in re-factoring in that sense, so including the motivation behind the change (which is to improve the software) is part of selling re-factoring as a worthwile behavior.

Having said all of that, I think 'harmful refactoring' or 'negative-value refactoring' or 'failed refactoring' is a perfectly good word for 'changes that degrade a piece of software's internal design or structure while preserving the visible behavior'.

Answer 5

Refactoring does suggest intention. Changes to program code which are done for reasons other than improving the structure of the code are often referred to as organic changes. Code which grows organically is an accumulation of changes which were not made intentionally to improve the structure, but were made for other reasons such as expedience, optimization, or other reasons. These changes are the source of what is often called technical debt, usually a negative consequence of software engineers having their judgement overridden or clouded by motivations other than code quality. A change which was not made with the intention of improving the design and which results in lower code quality could be referred to as accumulating technical debt.

Answer 6

It's tough to think of a case where you would use this --except perhaps as a slur against someone else's efforts --but I would say degrading the code.

to lower in character or quality; debase.
http://dictionary.reference.com/browse/degrade

to make the quality of (something) worse
http://www.merriam-webster.com/dictionary/degrade

Answer 7

The opposite of Refactoring is Hacking, in its original sense - The act of shoving a change into the code regardless of how well it fits, just to get it to work.

Hacking is an intentional change to the code, that makes the internal structure worse.

Answer 8

While more of a corollary than an antonym, there is also the concept of a Transformation.

A transformation is a change to the behavior of code without change to its structure.

Transformations are at the core of "Uncle Bob" Martin's Transformation Priority Premise.

Answer 9

Considering the fact that spaghetti code is a legitimate term among programmers I would imagine that the following phrases would be understood as well:

Dan completely spaghettied the code base

Don't let Dan spaghetti the code again

What's Dan doing over there; is he spaghetti-ing the code again?!

Great, now we have to un-spaghetti Dan's code

Answer 10

Ossification

Sometimes we talk about code ossifying. Refactoring is a progressive process of sorting out and ordering code to make it easier to work with. It's an ongoing process which keeps the code up to date with evolving theory.

Ossification is the opposite: where you leave code alone for a long period until it sets hard.

Code which has not been refactored for a long period may be said to have ossified, it has become unmaintainable and is now impossible to understand or penetrate. It can no longer be refactored.

This process of sustained non-refactoring until you reach a frozen state can be referred to as ossification.

For example, I worked with a client a while back whose core business model was a million line Perl-ball. This code had ossified, it had suffered from an absence of refactoring for a sustained period and was now unrefactorable.

Answer 11

Defactoring

What about defactoring?

Defactoring is the process of removing factoring from code. 1

This is structurally an inverse operation: de-extracting (reinjecting) an extracted method, for instance.

1. "Defactoring" blog post on raganwald.com, 2013

Answer 12

The word "cruft" is a well-known term in software development jargon, and is defined by oxforddictionaries.com as:

Badly designed, unnecessarily complicated, or unwanted code or software

Code that is deemed inelegant by the reviewer is often referred to as "crufty".

From this, one might refer to the process of making inelegant changes to a codebase as "cruftifying" it.

Answer 13

One antonym that comes to mind is "bit rot" as in "The bit rot has really got into this codebase it needs a total rewrite".

Answer 14

Perhaps sprawling, unstructured growth of code. It's not necessarily spaghetti code -- it's just not well structured. And it's not bit rot either because bit rot happens as a response to a changing environment even when nothing in the program changes.

Like the other suggestions, sprawling is not an exact antonym because it is not intentional; at best it is negligent. And sprawling code usually is programmed when explicitly changing the program's behavior.

Actually, in this sense it is also an antonym!

But I have the feeling that this was what you meant.

Answer 15

How about coining a new word for this: entropying the code.

Answer 16

"Improving readability" If an organization has strict style guidelines, there may be a requirement to reduce technical debt by reformatting entire files to match the guidelines every time the file is touched. This is an accepted practice, and may be useful if the existing codebase has multiple conflicting styles, especially in a single file.

OTOH, frequently the reformatting is merely a case of "marking" as dogs do to trees, and an opportunity to claim to have "cleaned up" the file. A common practice of egotistical programmers is the re-formatting of already well-formatted and readable code and/or the renaming of already well-named symbols so that code matches their unique style. The problem with such behavior is that it makes it much harder to identify real changes, as every commit will have dozens or hundreds of meaningless changes.