Someone complains that members of his team are patching code instead of improving it, and therefore Extreme Programming isn't "scalable". The fact is, this lesson about the inappropriate use of "patching" is something that needs to be learned even if the team isn't doing XP. If it is doing XP, they are going to learn this lesson more quickly and more obviously than they would in a non-XP environment: their velocity is going to slow down over time until they can't create any new user-value within a single iteration.
(From MemoRanda, which claims this is the permalink, but you might need to go to this one instead.)
I like the phrase "improving it," esp. in reference to my previous thoughts about the use of the phrase "rewriting code" vs. "updating code." I previously said this was a bit of "spin-miestery," but I've been thinking that the positive de-calcifying I was talking about isn't rewriting from scratch, but re-working code that was either broken to begin with, or is no longer able to provide the functionality you need in the way you need it, as quickly as you need it.
In the past, when confronted with these things, the gradual scaffolding approach seems to have worked well: you don't rip everything out all at once (rewriting from scratch), but you slowly replace small pieces of code with new code.
It's like Jenga, but instead of just pulling blocks out and rebuilding the tower all over again, you pull out blocks, but put new blocks back in place. Hopefully, the tower won't fall while you're doing this. Good test coverage is certainly a requirement, but it seem that just like Jenga it takes a slow, steady hand to keep the whole thing from falling down.
Previous Topic
