(Context: a chat session following a code review. Developer one has solved a bug in a really old piece of the system. The code change has been checked by developer two. Even though the bug seems to have been fixed, developer two has a suggestion to developer one)
Developer one: Why do you want me to extract a method here?
Developer two: Well I think it is a relatively simple change to do. It will reduce duplication, which is good.
Developer one: But the bug has been fixed, I do not want to change any more code!
Developer two: Yes the bug seems to be gone, I could not reproduce it. But I still think you can improve the code here a little.
Developer one: But it is such an old part of the system, and we are going to throw away this whole pile of mud anyway in the future.
Developer two: Yes I agree, this part of the system is old and messy, but giving it a little love will make it less messy, and reduce the risk of finding more bugs slightly.
Developer one: I will do it this time, just for you. Are you happy?
Developer two: Thank you. You could view it as a refactoring exercise if you still think I am not making sense.
Developer one: Yeah sure.
Who is right and who is wrong in the above conflict? I cannot say developer two is always right regardless of situation, even though I feel strongly about DRY (upcoming topic) and PITS. Sometimes it is necessary to just step back and be pragmatic.
However, I do think it is up to developer one to explain why he or she does not want to improve the code while fixing a bug. If a good reason comes up–release tomorrow being one good excuse I would accept–skipping the refactoring could be an example of Use Your Software – Brain and not being fundamentalistic.
A popular excuse for not doing the refactoring–just clinically fixing the bug–is the one about the broken architecture. If the design is perceived to be flawed enough to need a complete redesign – that is, if developers are complaining about a broken architecture, you might hear that it is not even worth spending the time to fix “small details”. Read The Castle in the Sky to find out what I think about that argument. Briefly, I think it is a bad excuse and will spread a culture that details do not matter.
When to stop?But when do we stop refactoring around the bug? For example, imagine if it was developer two fixing the bug. Probably a lot of things could be improved in the area of the code as we know it is both old and messy.
Of course there is no clear cut answer to this question. I try to follow a rule I like to call The Scouts’ Rule:
Scouts’ Rule: Leave the camp ground slightly cleaner than you found it
Doing a little refactoring, like extracting a method to reduce duplication locally around the bug, is a way to follow the Scouts’ Rule in the above scenario.
What kind of refactorings?
I like small, local refactorings better than big architecture changes. Small changes are less risky than big design changes. Also, many small changes becomes bigger as time goes by – so those big design improvements seem to happen anyway.
For a longer discussion on this kind of small scale refactorings, read about Programming In The Small (PITS).
Effects of Scouts’ Rule
If you are in a team that follows the Scouts’ Rule your source code will slowly improve. That is not hard to see; if every member improves the code a little each time they touch it, it will get better and better.
A good thing with this—apart from feeling good about improving code, and the cleaner house of code you are going to live in—is that management cannot really stop you from following Scouts’ Rule.
The reasoning behind that statement is that it actually makes sense for a product owner, or other boss type person, to block attempts of doing big or even moderate size refactorings. After all such things are risky, take time and do not bring immediate value to the customer*. However, the Scouts’ Rule is small in nature, and therefore avoids the “big risk” argument, and does not take much time either.
*of course, you know it brings value to the customer in the long term, by increasing the robustness of the code, and decreasing the time it takes to fix bugs. That is a real world value to customers, but long term arguments are hard to bring up in the rush of day-to-day work and deadlines.
How do I convince my team?
So you have understood how good this rule is, especially in a team. How do you put it to practice?
The simplest approach is by following Scouts Rule yourself, and use it to explain why you have chosen to do a little refactoring during bug fixes, but not big refactorings.
Slightly more work, but still quite easy, is putting a Scouts Rule poster on a wall that all members can see, and explain how it works when people ask.
Another approach is to convince the most influential member of the team. He/she might have a title such as team lead, tech lead or scrum master, and once convinced, he/she will spread this rule automagically to the rest of the team, just by being in that role.
The last suggestion is to talk to a boss figure, and making it a policy. The risk with this is the feeling of things being forced from above upon the team; however, if the team has good confidence with him or her, it might be viable.