Rob Smyth

Tuesday, 26 February 2008


Language is such an important thing in software development. Patterns are a the classic example, they provide a vocabulary to communicate concepts like 'it is like a state pattern would be useful'. Likewise we have adopted a vocabulary for agile style development. Like TDD, red-green-refactor, refactoring, and now (hopefully) 'prefactoring'. It is term, invented by Nigel, that has become common in our team (Varian Australia).

The first time it 'jelled' with me was when taking a class that was ... well ... hmm ... 'legacy' code. It was full of 'if' statements making the intent of the class difficult to see. We wanted to add a simple corner case to the functionality. Nigel suggested to prefactor the code so that it would become self evident where to make the change. He meant refactoring done prior to change as opposed to the RED-GREEN-REFACTOR it was added a PREFACTOR initial step. The feature seemed to simple I thought 'na ... I can find were to insert this little bit of code with the time to refactor/prefactor it'. But half a day later the code was still bucket of worms.

So, "delete plan A and insert plan B" we did then try Nigel's idea of prefactoring. Prefactoring means refactoring the code prior to making the change so that the code's purpose is self evident. Or, in other words, where to insert the change is self evident (I will avoid a discussion of open-close principle for the moment). So when I said 'we did then try' I was using the royal 'we'. In other words off Nigel went prefactoring/refactoring the code. After just 3 hours the code became clear like a ship emerging from a fog and the change needed was just easy.

So, if you are confronted with unintelligible code to maintain, prefactor. It saves time.

Should we now say PREFACTOR-RED-GREEN-REFACTOR. Na, that just means you did not refactor last time.

Go Nigel!


Nigel Thorne said...

Thanks for prompting me to post on this Rob.

Just one thing.. Sometimes even when you did full TDD you still need Prefactoring.

Namely when you have a new feature that won't fit until you change your existing design.

Philip said...

Unfortunately a little googling shows that the term "prefactoring" has a lot of momentum in the industry but referring to a different practice.

See Prefactoring

While Nigel's proposed practice is worth promoting, you'll need a catchy neologism.

Perhaps steal a coinage from the building industry like "refoundationing".

Unknown said...

Ok, looking for another word for this.

Sounds like what Nigel did was make the code speak more clearly. Clarify. De-coding the ideas that we couldn't see clearly expressed, and coding them so they are expressed. (sounds like one of Kent Becks rules for simple code)

I get a bunch of people describing doing something like what you did by googling < refactoring to understand code >.

I don't see a word for it though.

Well, didn't find a word, but maybe someone else will.