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.