The Refactoring Butler (a.k.a ‘The Core Cleans Up’ or ‘Shadow Repository’)
Cleaning up a team members code. Ever done that? Repeatedly? While mumbling to yourself or maybe saying to your pair programming partner
– “Why do they keep polluting the code – Stop it already!”.
Only to find that while you where tidying up some code here, there is new stuff in the repository waiting to be update or even merged.
– “I wonder what this update might contain …. Yiiiipes!”
Sitting there, wishing that your team buddies would not check in code into the real repository but a shadow one will not make you more effective. If you are planning on working side by side, effectively with them you might want to consider another approach. Because the longer you work one the code base, the bigger it gets and it will need more and more attention. Cleaning up, alone, does not scale.
What to do then?
I would recommend a discussion about code quality. What is good, clean code. What are you willing to do to achieve that. What is acceptable, what is not. These kind of questions has to be answered. There are a few techniques to get this kind of discussion going but I will not get into that here. Once going it will probably last for a good couple of hours. And it will certainly help a lot to have an external person, a person with little or no interest in the team itself, as a moderator.
The result of this discussion should be some sort of consensus around the code quality and the processes of getting there. Some sort of working agreements might help to sustain the behavior.
Thanks to J.B Rainsberger for the wonderfully colourful term ‘Refactoring Butler’