Refactoring Pitfalls

Although we can extract a lot of benifits from refactoring, we should not forget that it could also have some pitfalls, so we should apply it wiselly.

Pitfall #1 – Large refactorings

Refactorings that feel like they should be easy yet take a long time; you could end up getting only halfway done, which means your code is worse that it was at the start (since now it expresses the same thing in two different ways).


  • Be creative about finding smaller, yet consistent refactorings.
  • Set a timer for 20 minutes; if you’re still getting started or still trying to figure out what to do, give up and try again with something smaller.
  • Break the refactoring into small pieces, and then after each piece is done, re-evaluate whether you need to continue.

Pitfall #2 – Customers

Customers hate refactoring, since it doesn’t add value. They will press you to add more features. (Note that this pressure can actually be good! It can help keep you from thrashing)


  • Refactor a little at a time, all the time.
  • Make sure big refactorings are bounded, and have a specific performance goal.
  • Don’t tell the customer that you need some time away from the stories to do some refactoring.
  • Don’t write “refactoring stories”.

Pitfall #3 – Thrashing

Endlessly refactoring the same code to be marginally better (or just different) without contributing to velocity or to business value.


  • Try to make every refactoring with a specific story or task in mind (maybe only in the back of your mind); hoping that as soon as you’re done with this refactoring (and maybe just one or two more) you can finally implement the task.
  • Discuss the refactoring with the team so see if other people think that you’re not going to get much out of the refactoring.
  • Work with a partner. Your partner should be able to tell you when you’re gold-plating.

Pitfall # 4 – Refactoring and Collective Code Ownership can cause disorientation

People may sit down and see code that looks completely foreign. This may require people to re-learn the whole system, or (worse) to make them feel like they have to relearn it when all they want to do is write some code. They get a sense of nausea and vertigo when sitting down to look at code, and there’s no high-level view, and this hurts morale and productivity.


  • Automatically generated object/architecture diagrams
  • Sketch a rough object model diagram as soon as you sit down with unfamiliar code.
  • Ask for help from someone else who understands the component.
  • Refactor to understand.
  • Do far-reaching refactorings with a projector and the whole team.[Has anyone tried this?]
  • When you’re done, take a few minutes for a show-and-tell.
  • Work with a partner.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: