Rules of Refactoring Club
Posted on Monday Aug 03, 2015 at 09:09PM in Technology
with apologies to Fight Club
You do not talk about refactoring club
Obviously, as a developer you will need to talk to other developers and architects about refactoring. But talking to non-technical people from the business (e.g. product owners) about refactoring is unlikely to be productive. Unless they used to be developers themselves, they won't appreciate its importance.
So how do you persuade them to allow you or your team to get on with it?
My suggestion: don't persuade, or even discuss, with the business. Just get on with it. Hopefully, you're in an agile team, committing to certain features per sprint.
- Include a certain amount of slack in your estimates.
- If there is a lot of refactoring to do, then include a large amount of slack. (Hint: how did you end up here?)
- Try not to include refactoring items as 'stories'.
- If there is so much refactoring that you need to track and prioritize what needs doing, use a different tool from your feature tracker. Do not waste your business people's time by showing it to them.
The earlier you do this, the better. Get used to including slack. There is always pressure to deliver features, but in reality, business people have very little idea what rate of progress to expect from a development team. At the start of an engagement, you have a great opportunity to manage their expectations.
You might be a little uncomfortable with this approach; it could seem dishonest. But you don't discuss the intricacies of git rebase vs. merge with your business people; your car mechanic does not ask your permission to unscrew each bolt. In my experience, it's the best way to ensure the business actually gets what they want from their software. Keeping quality high by constantly refactoring will allow you to deliver features more quickly as the project grows.
Martin Fowler takes a similar line in the discussion towards the end of this video. (In fact, just go watch the whole thing; this can wait)
You do not talk about refactoring club
Don't misuse the word refactoring. Martin Fowler can have the first and last word on what it means:
Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.
It does not mean 'change' or 'fix'. If you need to change or fix code, just admit it (unlike the previous point, I think it is fine to discuss this with people from the business.)
I've heard people say 'I refactored the screen to show X' or 'We need to refactor this API to allow Y'. What you're doing there is changing those things, because they're externally different afterwards!
Refactoring has a very domain-specific meaning, and it's hard to create satisfactory analogies (please leave yours in the comments, if you have one). Maybe that's why it's so hard to explain how important it is to non-programmers.
The meaning is lost if you use the word incorrectly, and the implication of past failure is hard to avoid if it starts to mean 'fix'.
One refactoring at a time
Within reason, obviously. If you're working in completely separate areas, it's not a problem.
Two people refactoring the same area at the same time will quickly figure out it's a bad idea when their source control starts spewing conflicts. If your team's communication is good, this won't arise, but large projects always have problems. Don't let well-intentioned refactoring get a bad name just because your developers aren't communicating well.
More subtly, make sure you finish your refactorings. There's nothing worse than some originally bad code, copy-pasted around, only some of which gets tidied up. Now the unfortunately soul trying to understand it will need to figure out two lots of code.
Unfinished refactorings sat on a branch are worse, because they will begin to rot as changes are introduced to main-line code that's affected; the refactoring might need to be applied to fresh code.
Refactoring will go on as long as it has to
There is always more refactoring that could be done; only you and your team can judge when it's necessary.
Be especially careful of refactorings deemed necessary for performance and scalability (this blog post is mostly concerned with refactoring for maintainability). I can't explain why, but in my experience, these kind of proposed changes seem to bring out developers' egos and encourage unproductive, non-consensual discussion. Having a rudimentary performance test framework in place early on in the project will help here.
If it's your first night at refactoring club, you have to refactor
In agile software, design emerges throughout the development process rather than being handed down from on high. It doesn't emerge spontaneously: refactoring is what makes it happen.
Encourage everyone, even junior developers, to refactor constantly. They'll be able to develop their design skills, in a relatively safe way (you do have lots of automated tests, right?). It's a great way to spot who has potential to be a 'star' programmer.
Code reviews are another useful tool for pointing out opportunities for refactoring, as long as you don't overdo it. Sometimes it's best left for another merge request.