Comments on: Plan to Refactor

By: Jason Yip

Jason Yip — Sat, 31 Dec 2005 01:58:57 +0000

Just found this blog entry which expands on why I wouldn’t call this refactoring at the end, refactoring.
http://samgentile.com/blog/archive/2005/12/04/32144.aspx

By: Chet Frame

Chet Frame — Wed, 28 Dec 2005 22:18:36 +0000

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?”

By: keith ray

keith ray — Wed, 28 Dec 2005 10:40:11 +0000

“plan to throw one away” is that people at NeXT used to advise… and, ironically, the original waterfall paper by Royce.

By: Jason Yip

Jason Yip — Wed, 28 Dec 2005 02:04:43 +0000

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”.

By: Dave Smith

Dave Smith — Wed, 28 Dec 2005 00:09:41 +0000

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.

By: keith ray

keith ray — Tue, 27 Dec 2005 22:46:48 +0000

Good advice, Dave, though Johanna was specifically speaking to projects that are NOT agile.

By: Dave Smith

Dave Smith — Tue, 27 Dec 2005 19:24:23 +0000

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.