Go Faster With Refactoring

Clearly developing on a clean code base is faster than on a dirty one, but is it fast enough to warrant cleaning all the time? We believe it is, but we can't prove it. Here's some discussion.

On the C3 project, we fell away from our practices for a while, and the code space got quite messy. We noticed that our development pace slowed down. LoadFactor seemed to be the same, but real EngineeringDays to do things were getting larger and larger than estimated. We talked about it, and determined that the code base was crufty and slowing us down.

We scheduled a refactoring iteration, where we accepted fewer UserStories than usual, by setting our LoadFactor to 3 (up from 2 at that time). We cleaned up the system, and our estimates came back on track. We gained speed and the ability to predict progress accurately. Was it worth the slower Iteration? We think so.

OK, if the code base gets too crufty, cleaning it up may be useful. Does that mean it's worth it to do it as you go?

We argue yes, because if you do it as you go, it factors into your load factor, giving you consistently predictable progress. We also think it's more effective because CruftMultiplies. Refactoring isn't a cost, it's an investment with immediate returns. RefactoringIsntOverhead.

There's a FineLineBetweenRefactoringAndFutzing.

This page mirrored in WikiPagesAboutRefactoring as of April 29, 2006