Refactoring – an (amateur) etymology

The Yahoo XP group has been having a fairly heated debate about the term “refactoring”. When you refactor, do you change the behaviour of your code, or not? I decided to go have a look on dictionary.com, my ever-ready friend, for a definition.

It didn’t have a definition of “refactor”. It did, though, have “factor”, particularly as relates to the phrase “factor in”:

factor in
    To figure in: We factored sick days and vacations in when we prepared the work schedule.

For me, that implies that the thing associated with the factoring in changes as a result of the new information.

Here’s where Dictionary.com says the word “factor” comes from:

[Middle English factour, perpetrator, agent, from Old French facteur, from Latin factor, maker, from facere, to make.]

We associate the root “fact” with “making things”, like factory. So sometimes I think of “refactor” as “remake”, which usually implies that there was a flaw in the original, or some new requirement, necessitating the remake. That means changing the behaviour.

I guess if you have a “refactoring phase” or you explicitly separate the idea of tidying up the code from remaking it, you might want to insist that refactoring shouldn’t change any of the code. I don’t think of refactoring as a process, and I haven’t found “refactoring phases” useful except as a smell that I’m not doing it enough as I’m going along. I just change things to put new behaviour in, so any “refactoring” I do is usually accompanied by a change in the code.

Refactoring techniques, though, are important tools that mustn’t change the behaviour of my code, because otherwise I won’t be able to control the explicit changes which I’m trying to make. I guess that’s where I see the confusion coming in. Refactoring isn’t a process. It’s just another tool, or a set of them, which lets me maintain my relationship with my code. My relationship with my code involves legibility, maintainability and predictability, and that particular behaviour should never change.

Update: An anonymous friend comments:

The ‘factoring’ in re-factoring refers to how something is made up. For example, 12 can be (6 + 6) or (4 + 4 + 4). Refactoring the code is changing it from two 6s to three 4s.

That makes sense; I wondered where the original use (ie: non-behaviour-changing transforms) came from. Aren’t words fun?

This entry was posted in Uncategorized. Bookmark the permalink.

4 Responses to Refactoring – an (amateur) etymology

  1. anonymous says:

    The ‘factoring’ in re-factoring refers to how something is made up.

    For example, 12 can be (6 + 6) or (4 + 4 + 4). Refactoring the code is changing it from two 6s to three 4s.

  2. sirenian says:

    That’s a good point; I’d like to add it to the main post, if you don’t mind. (If you do, please tell me and I’ll take it out. I’d ask, but I don’t know who you are!)

  3. yatimk says:

    I did not participate in the XP list discussion, because it was… well… heated though insignificant. But as a side note, the use of the word refactoring to refer to a behavior-preserving transformation, this use probably is similar to “remake.” That is, we have something, it does what we want, but it doesn’t do it exactly the way we want it to. So let’s remake it, to do the same thing but by a different method.

    The etymology of language can be funny, and you can’t really rely on it to determine the meanings of words. Look at the word bar, for example. It refers to a long, straight, rigid piece of solid material, thus to a horizontal structure at which lawyers used to serve. The word remains in a related sense, even though the physical bar is lost in history. Also, a bar is a counter (a “bar”) on which drinks are served as well as an establishment containing such a bar. All these senses of bar are related.

    Now, I do something I call “refactoring.” It involves changing the structure of code without changing its behavior. As a professional, I only refactor in order to improve the design, and then only if I expect that improvement to pay off immediately. Also, I tell whether or not the behavior has changed by running the tests. Ancillary behaviors may in fact change, but as long as all tests still pass, including manual tests, I consider the refactoring to be sound.

    -TimK

  4. sirenian says:

    Sure. I think of refactoring techniques, and I do also think of refactoring phases in the same way – as behaviour preserving.

    Unfortunately, my behaviour-preserving transform and their behaviour-preserving transform have just collided in merge to completely change the behaviour of the system, dammit. This happens so often that I think the idea that refactoring can, and sometimes will, change the behaviour of a system – and that I need to be aware of that, and watch out for it – is important. More so than arguing about the definition of refactoring, or whether a refactoring phase should be purely about maintaining behaviour, etc.

    More often than not, the change helps anyway. This time it didn’t, and it took me an hour to track down.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s