Grand Refactoring Day

You have a group that's adopted a lot of ExtremeProgramming. They're TestInfected, they PairPromiscuously, they estimate and deliver UserStories, and they've achieved good buy-in from customers and upper management.

But they don't refactor much. Maybe they refactor their own code, but they don't religiously follow ProjectStandards, and they're loath to refactor someone else's code. In a nutshell, they're trending away from CollectiveOwnership of the codebase and they're beginning to implement things SeventeenTimesAndOnlySeventeenTimes.

The excuse for this is that some team members go faster than others, and everyone's anxious to increase speed by keeping out of the way of those fast guys. This is especially true when people have very different fields and levels of expertise. But the result is that the whole group is slowing down and cruft is beginning to happen.

Therefore:

Hold a GrandRefactoringDay. Pair 'em up, and tell 'em to range over the whole codebase, refactoring anywhere they can.

Make certain they understand the Fowler/Beck CodeSmells first. Allow time for the less experienced team members to read the refactoring book before getting stuck in.

To heighten the drama, tell 'em to try to avoid refactoring any code they wrote themselves. Make their brief to go monkey with other people's code - but formally, using tiny little steps, and making certain UnitTests run between each step.

What will happen is that a lot of code will get broke - you'll discover that some of your folk aren't writing adequate tests. You'll discover that some are too ambitious about a refactoring and get stuck, while others are too cautious with the unfamiliar bits. TheCoach should counsel these folk gently, and pair by example with those who are having the most trouble.

Afterwards, let regular development flow tidy up the messes over the next few days. There will be grumbles, but most folk will come to understand why RefactorMercilessly is a necessary part of the game. Those that don't will nevertheless act accordingly when there will be other GrandRefactoringDays held in the future.

Discussion:

Doesn't the grandiosity of GrandRefactoringDay reinforce the original habit of not refactoring by giving them a reason to put it off? This seems like a good ice breaker, but how do you get refactoring onto a short cycle and keep it there?

Perhaps GrandRefactoringDay could be snuck in at the beginning of a new release, or a maintenance cycle, when everyone agrees that the task is first to clean up pending low-priority bugs and then to add new high-priority features. Bugs-to-be-fixed could be assigned at random to programming pairs, with encouragement to not only fix the bug as reported but also "clean up the code" that touches or is touched by the buggy area. In my experience, it takes very little support from management for programmers to become quite enthusiastic about rewriting other programmers' code. After a couple of cycles going through this, then put GrandRefactoringDay in the schedule and programmers will think, "Oh yeah, I know what that's about." -- ChrisBaugh

If the programmers are not refactoring now, I'm not certain that a GrandRefactoringDay would change anything. I'd guess they just spend the day reading e-mail and web surfing. My alternative is to pick a section of code that has been causing problems and assign one team to clean it up. This is best done at the beginning of a project cycle. Repeat this until the programmers start refactoring as they write. -- WayneMack

On the contrary, I've participated in several GrandRefactoringDay exercises. The point of view I've brought in is that I'm very experienced in certain patterns and tools. That sort of expertise is not often found in project teams that have bootstrapped themselves into the distributed-programming and object-relational arenas. I come in and share the wealth of the patterns for a day and then we hold a two or three-day refactoring party to introduce the patterns. It only usually takes a week total, and the code usually looks MUCH better at the end. By then the programmers have internalized the new patterns and can do it themselves.-- KyleBrown

CategoryRefactoring