When pairing with other people I always find it interesting to see what their programming workflow is like. Most people I know TDD out their code and like to follow some form of the Boy Scout Rule:
You should always leave the campground cleaner than you found it Robert C. Martin (quoted in the context of programming)
When this common Boy Scout Rule is applied to computer programming, the camp ground becomes your code base and cleanness typically refers to the traits that Bob Martin talks about in his book Clean Code. That is, code that does not violate YAGNI, KISS, is well refactored, pleasant to read and easy to understand. When working on an existing code base it doesn't take long to find an area of the code that could be improved, following the Boy Scout Rule means that it is now your responsibility to leave the "camp ground" cleaner then you found it. So it is time to roll up your sleeves and refactor the existing code until it is clean.
The extreme flip side of this are people who don't follow the Boy Scout Rule at all and simply dive into the code base and make whatever changes are needed to get the job done and walk away. The side affect of this carelessness is a code base with a high technical debt and a lot of angry coworkers. The strict application of the Boy Scout Rule results in the continual improvement in the quality of the code base at every commit. This is because everyone is doing their bit to improve every piece of code that they come across.
What I find interesting when pairing is when people decide to do their cleanup. Do you do it at the end of the task you were starting? Or do you do it at the end? I once read somewhere (can't remember where) that Kent Beck and Martin Fowler like to keep a list of cleanups or debts that they discover while they are developing a story. They prefer to keep them on a list, and only refactor what is needed to get their functionality working. Once the functionality is done, then it is a good time to start refactoring that solution into something nicer. Of course, sometimes you can't even start your story until some heavy refactoring is done. So this, like all rules, can not be applied everywhere blindly. Previously, I use to prefer to refactor the code as soon as I found a problem with it. What I found is that I would spend an inordinate amount of time cleaning up code that wasn't contributing directly to the new piece of functionality I as working on. So instead, I've tried to find balance by setting a few rules:
- Only clean up existing code before completing the functionality if it will help with understanding and if it is low in risk and effort
- Only clean up existing code before competing functionality if it is really required before the functionality can be implemented well
- Leave all large potentially risky refactorings until after the commit for the new functionality has been completed
- Never perform a clean up on existing code with a working base that has uncommitted changes
- Draw a strict boundary of where the camp ground ends, mark and leave those messy areas for another day
Following these set of rules, I've been able to find a suitable balance between working effectively and efficiently and not loosing sleep over leaving behind a dirty camp ground.
