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.

  • 9
    'refactoring' does not just mean 'improve a system' so its antonym would not have a meaning of 'worsening or deteriorating a system', therefore the question has dubious meaning. Refactoring' has the specific meaning you cited and so its antonym would presumably mean "[the process of] changing [the] system without altering the external behaviour of the code yet degrading its internal structure".
    – Marv Mills
    Commented Oct 6, 2015 at 14:48
  • 1
    @rainbolt good point, though expressed in a slightly confrontational way, there is of course the other possible antonym whereby the external behaviour of the code is changed without improving its internal structure, but presenting multiple versions was too much for one comment and, in fact, that one is just "a change". Pick which bits you want to hold constant and which to invert, but either way neither of them has the meaning "worsen or deteriorate the system"...
    – Marv Mills
    Commented Oct 6, 2015 at 15:26
  • 7
    The action "of worsening or deteriorating the internal structure of a software system" is also a refactoring, but a "harmful refactoring".
    – Graffito
    Commented Oct 6, 2015 at 16:28
  • 6
    Yes, that definition is wrong. Refactoring means making a significant architectural change - not every change is a refactoring, and it is still a refactoring even if it is not actually an improvement. (There is a natural assumption that it is at least intended to be an improvement, because intentionally damaging the code would be irrational, but success is not part of the definition.) There is no true antonym, IMO, any more than there is an antonym for "redecorating" or for "renovating". Commented Oct 6, 2015 at 21:02
  • 5
    @HarryJohnston "There is no true antonym." is a perfectly valid answer.
    – Rainbolt
    Commented Oct 6, 2015 at 21:15

16 Answers 16


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.

  • 2
    ...and another +1 for "software entropy"
    – J.R.
    Commented Jan 26, 2017 at 15:45


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!


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.


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


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.


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.

to make the quality of (something) worse


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.


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.

  • what i was looking for. thanks!
    – Ore4444
    Commented Apr 7, 2020 at 21:42

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



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.



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

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.


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


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.


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

  • That sounds weird. inquiry -> inquiring, entropy -> entroping?
    – Mitch
    Commented Oct 8, 2015 at 15:02
  • This might be not bad as a start. Entropy change is related to heat transfer. Other words might be cooked or fried code, but somehow not fixed :-)
    – mlt
    Commented Oct 8, 2015 at 19:59
  • I was thinking more in terms of the part of the definition of "entropy" that goes like this: lack of order or predictability; gradual decline into disorder. "a marketplace where entropy reigns supreme" Thus, "entropying" -> code becoming less ordered as an antonym of "refactoring" -> code becoming more ordered. Commented Oct 9, 2015 at 3:59

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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