Prefactoring evolved from a “Birds of a Feather” session at a Software Development conference in Washington, D.C. Martin Fowler, Ron Jeffries, myself, and several others discussed why software came to need refactoring and practices that might be used to lessen that need. Spurred by that discussion, I compiled a set of guidelines for creating software and entitled it Prefactoring.

Refactoring, according to Martin Fowler, “is a controlled technique for improving the design of an existing code base.” “It does this by applying a series of particular code transformations, each of which are called refactorings.”. “’Code smells’ suggest refactoring, “

Prefactoring guidelines emphasize things to think about before you start coding. Refactorings are code transformations performed after you have created code.

The prefactoring guidelines encompass some that are directly related to code transformations and others that are not. A commonly used refactoring is Extract Method. The “Separate Policy from Implementation” prefactoring guideline suggests organizing methods into ones that perform implementation (e.g. totaling a customer’s purchases) and ones that perform policy (e.g. giving the customer a discount based on total purchases). If you think about this guideline as you develop the code, you may find yourself separating many methods, and therefore requiring fewer Extract Methods. Separating policy from implementation is not an operation you can perform mechanically. It’s something that you have to do intentionally. Coding with intention makes your code start with less smells.

Other prefactoring guidelines do not deal with code transformations. “The Easiest Code to Debug is That Which is Not Written”.guideline suggests that you use Google as a development tool. Before even writing a single line of code, google to see if the feature you are about to create exists in either open source or commercially available software. If it is, check it out. You may get away with not having to write a single line of code. Even if the software doesn’t work out, you’ll have an opportunity to see how others have approached a solution. Developing software is not just about writing code; it’s about delivering solutions, regardless of how they are created.

There is no “big design up front” in prefactoring. The “Think About the Big Picture.” guideline is not about big design. It suggests that you spend a little bit of time investigating the environment in which you are going to create your software. The environment (e.g. a corporate infrastructure, J2EE, or web services) may provide numerous services (e.g. security or error handling) that you don’t need to develop or it may suggest ways for structuring your code to fit into the framework.

Following the prefactoring guidelines does not mean you don’t refactor your code. The guidelines can help keep the smells out. . But when code starts to smell, refactor it. As you go through development, you gain more knowledge about the total project, which can generate new ideas. Performing a retrospective after every release, as one guideline states, can help direct this generation of new ideas.

Agility is about delivering working software to the customer. Iterative and incremental development and customer communication, as shown in the example in the book, are key principles to enable that delivery. You can use multiple tools to achieve the goal – refactoring – performing transformations on created code is one tool, prefactoring – thinking about things before coding is another.