Twitter GitHub Facebook Instagram

Daniel Irvine on building software

What refactoring isn't

4 October 2012

Let me just state this up front: changing code for the sake of change is not okay and should be forbidden by any decent software development process.

This happens frequently enough for it to be a problem. Developer Joe comes along and notices code that his teammate Developer Sue wrote, but unfortunately he has a problem with it. Not a problem as in, there’s an error in this code, but a problem as in this isn’t written in my style and I don’t understand it. The temptation is there for Bob to modify the code so that he understands it and it’s to his liking, so he goes along and does it. What’s worse, this is done under the guise of “refactoring”, which is an abuse of the term. Refactoring is changing code when it facilitates a new feature to be built on top of the changed code, not changing code without a functional purpose.

Often this change is just little things like breaking out methods, adding comments, pulling out local variables, changing the structure of loops or changing the scope of try/catch blocks.  But any change, no matter how small, can introduce bugs. And that’s exactly why we shouldn’t do it.

This temptation to make this kind of change is great, and that’s because it’s the easy mental approach. The more difficult mental approach is to leave the code alone and study it until you understand it.

Leave that code alone! Seriously. If code has been released and is in production use, then all of the following apply:

  • it has been tested (since it’s being used)
  • it works to a reasonable level
  • it may have been code reviewed
If you modify that code, none of those things apply anymore. So it might make it easier for you to understand that code, but it makes everyone else’s life harder and increases your team’s workload as that code now needs retested and redeployed.

About the author

Daniel Irvine is a software craftsman at 8th Light, based in London. These days he prefers to code in Clojure and Ruby, despite having been a C++ and C# developer for the majority of his career.

For a longer bio please see To contact Daniel, send a tweet to @d_ir or use the comments section below.

Twitter GitHub Facebook Instagram