Tilca Technology Technology updates and thoughts from Tilca

Rules of Refactoring Club

by Art

Posted on Monday Aug 03, 2015 at 09:09PM in Technology

with apologies to Fight Club

  1. 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)

  2. 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'.

  3. 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.

  4. 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.

  5. 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.


There's another reason to refactor code locally: To understand it, to find the essence of the design. And the way it skewed away from the essence over the years. I don't commit every refactor, sometimes it's just too tricky and it's better to leave the code intact and put the findings from the attempted refactor in the comments, to help future developers (future me) to understand the code. I always compare refactoring with the processes that take place in my brain when I'm resting and sleeping. I process the experiences of the day, separate useful information from noise, rethink convictions, rebuild my mental images about the world, based on my new experiences. I try to do that on a daily basis. When I don't, I get burned out sooner or later and that's similar to crufty and unmaintainable code.

Posted by pixelbart on August 07, 2015 at 08:07 PM BST #

Refactoring can be translated as "making the clock run from a different clockwork". Now this also allows for the positive side effect that the clock may run more precisely than before, and it's not even wrong to refactor towards the goal of running more precisely, despite that the article appears to state otherwise. The clock shows the correct time within reasonable expectation, and maybe refactoring just is about tackling the question about what is a reasonable expectation, instead of the visible details of the clock.

Posted by mar77i on August 08, 2015 at 08:08 AM BST #

I absolutely adore your blog. It is flawless and you have an inconceivable composed work style. Well done on your composed work style: you ought to be so happy for yourself.

Posted by Write My Essay on January 23, 2018 at 05:17 AM GMT #

Leave a Comment

HTML Syntax: NOT allowed