Prefactoring re-coined

Two pieces of input struck me this week that caused a bit of a brainwave.  The first stimulus I chanced upon was Michael Feathers’ article on the sloppiness of refactoring, in which he proposes a nice solution to getting the habit of refactoring to completion: do it first.

For every story/feature that you accept in planning imagine how you would implement it if the code was in a state where it would accept the feature easily.  Then, create a task for that refactoring work and make sure it is done before the other tasks for the feature

I like this idea a lot, and I want to introduce it in to the working agreement (how I hate that term) of our team.  This would solve a lot of forgotten refactorings that seem to only be remembered at retrospective time.

The second thing that I chanced upon is The Mikado Method book.  In it the authors propose a method for improving legacy code that begins with determining the dependency graph for the mini-tasks in the implementation, then starting the work at the leaves of the graph (these are the most independent areas of change in task).

What both these approaches essentially give us is a pre-refactoring step in implementation.  I was so excited by both these commalities that caused me to coin the term Prefactoring.  Imagine my dismay at learning that not only Prefactoring was already coined as a term in our lexicon, but also that there was even a bookImage may be NSFW.
Clik here to view. written with that title.  Unfortunately it means something entirely different…

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.