What you call time to code new function involves rewriting old function. Not that you have to, you just choose to. That is "wasted time" according to my penny pinching management. But it comes with ExtremeProgramming, just like documenting comes with other work styles. So refactoring time reads to me like a substitute for documenting time. In fact I wrote this on another page somewhere and you agreed. Where I am going with this is that a model of productivity for ExtremeProgramming should take into account the time spent refactoring. -- AlistairCockburn
It would be a good thing, as Alistair suggests, to be able to model the effect of refactoring on ExtremeProgramming
speed. But we don't have to model it to know that we must do it to be effective.
In the context of the other ExtremeProgramming rules, refactoring is necessary to ensure that the code meets quality standards. It also helps development go quickly.
If you use YouArentGonnaNeedIt
and the other ExtremeProgramming
practices, the emergent property is that you are doing iterative development. You choose consciously to go as fast as possible to add functionality in order to learn most rapidly what it is you are trying to build.
have suggested elsewhere, these practices, unchecked, would lead to hideous spaghetti code, redundant and conflicting implementations, code bloat, unreliability, and nuclear winter. The DoomSayers
are correct: you need something to balance quality against the pace of learning.
To ensure that these evils don't occur, ExtremeProgramming
explicitly includes the rule to RefactorMercilessly
. We interpret DoTheSimplestThingThatCouldPossiblyWork
not only to mean to pick the simplest solution, but to pick the simplest (least redundant, most communicative) code to do it with. It is this refinement process that reduces the chaos that would otherwise be caused by a rapid evolutionary process like XP's.
If we were to apply the other practices without concentration on refactoring, the code would become increasingly hard to maintain. Progress would slow. This isn't just a belief, the C3 project experienced the problem. See GoFasterWithRefactoring
. -- RonJeffries