Plan to Refactor


One of the scheduling tips I discuss in my project management workshops is “Plan to refactor.” I explain that if you're using a lifecycle other than Agile, where the integration and testing is built into every iteration, you're going to have to refactor at the end, when you do integrate and test.

At one of the workshops, one of the participants said, “You always have to plan to refactor. If you do plan for it, you will. If you don't plan for it you will, anyway. So plan for it.”

File this under wish I'd said that.

7 thoughts on “Plan to Refactor”

  1. An alternative is to not plan separately for refactorings, but to account for them in each task estimate. That is, treat them as a normal part of coding.
    An XP team I’ve been working with found that adding 20% seems to account for pre- and post-refactorings that a task raises. As long as we say “this task will take X” and deliver consistently, our stakeholders seem satisfied.
    Architectural restructurings are a separate matter. A lot of people bundle these in with refactorings, reasoning that they preserve semantics. We don’t, and account (and plan) for them separately.

  2. A problem we often get into in development is that of accepting an impoverished definition of what “done” means, and then having to argue and plead for extra time to get to a more satisfactory state. Agile development practices sidestep that problem by fixing the definition of “done” to include unit tests and refactoring. That definition doesn’t require being Agile, but it does require courage.

  3. Since you’re talking about a non-Agile lifecycle, which I assume means one that does not actually do continuous refactoring, I would not call it refactoring. Besides, I suspect that what you’re describing is not behaviour-preserving? So this is more like “Plan to rework”.

  4. Picking up on Dave’s point about the impoverished “Done,” there exists in most cases a minimum acceptable point that can be considered done and then there is a more robust concept of complete and tested and found to be correct in all aspects. Is it not the teams’ responsibility to insure that all deliverables meet the second unless the PM, for whatever reason, allows the first? If all deliverables meet the second condition, is the refactoring not included in “Done?”

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: