Saturday, 20 August 2011

Code Refurbishment

Within our industry we use a huge range of terminology.  Unfortunately we don’t all agree on what individual terms actually mean.  I so often hear people misuse the term “Refactoring” which has come to make the business in many organisations recoil in fear.  The reason for this fear I’ve observed is because of what people often mean when misusing this term.

I feel we are holding back our industry by not being disciplined in our use of terminology.  If one chemist said to another chemist “we are about to perform titration”, both would have a good idea what is involved.  I believe computing is still a very immature science.  As our subject matures hopefully we will become more precise and disciplined in our use of terminology and thus make our communication more accurate and effective.

Refactoring is a very useful technique for improving code quality and clarity.  To be precise it is a behaviour preserving change that improves a code base for future maintenance and understanding.  A good example would be extracting a method to remove code duplication and applying this method at every site of the duplication, thus removing the duplication.  Refactoring was first discussed in the early 1990s and became mainstream after Martin Fowler’s excellent “Refactoring” book in 1999.

Refactoring involves making a number of small internal changes to the code structure.  These changes will typically not have any external impact.  Well written unit tests that just assert externally observable behaviour will not change when code is refactored.  If the external behaviour of code is changing when the structure is being changed then this is not refactoring.

Now, why do our business folk recoil in fear when this simple and useful technique of “refactoring” is mentioned?  I believe this is because developers are actually talking about a much more extensive structural redevelopment technique that does not have a common term.  These structural changes are often not a complete ground-up rewrite because much of the existing code will be reused.  The reason the business folk have come to recoil is that they fear we are about to head off into uncharted waters with no idea of how long things will take and if any value will come out of the exercise.

This example of significant structural change reminds me of when a bar or restaurant gets taken over by new management.  The new management often undertake a refurbishment exercise to make the place more appealing and suitable for the customers they are targeting.  A lot of the building will be preserved and reused thus greatly reducing the costs of a complete rebuild.  In my experience when developers use the term “refactoring” what they really mean is that some module, or bounded context, in a code base is about to undergo significant refurbishment.  If we define this term, and agree the goal and value to the business, we may be able to better plan and manage our projects.

These code refurbishment exercises should have clear goals defined at the outset and all change must be tested against these goals.   For example, we may have discovered that code is not a true reflection of the business domain after new insights.  These insights may have been gleaned over a period of time and the code has grown out of step to become an approximation of what the business requires.  While performing Domain Driven Design the penny may drop with the essence of the business model becoming clear.  After this clarity of understanding the code may need a major overhaul to align it with this new understanding of the business.  Code can also drift from being a distilled model of the business domain if quick hacks are put in place to meet a deadline.  Over time these hacks can build on each other until the model no longer describes the business, it just about makes itself useful by side effect.  During this exercise our tests are likely to see significant change as we tighten up the specification for our new improved understanding of the business domain.

A code refurbishment is worthwhile to correct the core domain if it's about to undergo significant further development, or if a module is business critical and needs to be occasionally corrected under production pressure to preserve revenue generation.

I’m interested to know if other folk have observed similar developments and if you think refinement of this concept would be valuable?


  1. +1

    I support any effort to reduce misuse of the word "refactoring" and support its use the way Martin Fowler's book describes it. Usually when people say they need weeks to "refactor" something they're actually changing its behavior. In those cases it would be more honest to use such words as refurbish, rework, or even overhaul.

    I added a quiz question about this to the elearning module I'm writing.


  2. I completely agree. I've been saying for years (in response to a coworker saying they want to refactor something) - "No, you want to rewrite the code - this isn't a bad thing, but don't pretend you're going to keep the interface and functionality untouched".

    Of course I'm looked at as "whoa, somebody didn't drink the kool-aid!" or "that's what I meant". Grrr.

    If I were to be even snarkier about all of this I should retort to them - "you mean you're rewriting it to add more class bloat, and you're going to rip out all the comments!"

  3. Ok, then let the Refurbishment Patterns identification began.

  4. Yes: refurbishment and refactoring are two different, if complementary, things. Also see Uncle Bob's thoughts on a closely-related matter:

  5. Does any IDE supports refurbishment ? How do you come up with this man ?

    Difference between ClassNotFoundException vs NoClassDefFoundError

  6. Excellent point! I second the suggestion to introduce the term "refurbishing" as you describe.

    I've often noticed inappropriate reactions when I mention the term "refactoring", and this ambiguity is the cause.

    I mean "marginal improvement", they hear "massive transformation". Introducing the term "refurbishing" for the latter would clarify the communication.

  7. It's true that many people confuse refactoring with redesign. That said, we've also trained management for decades to fear and avoid code change. That's why we told them we needed change control boards to protect the system.

    We also find it difficult to make visible just how expensive inappropriate code is. In many organisations, "fixing the domain model" is heard as programmer gold-plating, rather than necessary maintenance so that further development doesn't grind to a halt.

  8. I like the idea, but I don't like the term 'refurbish' as a replacement. Refurbishing implies restoring the quality of something that has diminished from its original quality for some reason.

    If one of the primary reasons for not using the term 'refactoring' is because it's often misunderstood by non-technical folks, offering an inapt analogy may be counter-productive.

    A word that conveys the idea of tuning, optimizing, or polishing would seem more appropriate.

  9. I'm not suggesting anyone stops using the term "refactoring" for behaviour preserving change that improves the internal structure of code. This is established and I think many agree with it.

    "Refurbishment" does apply to the case where the code is no longer fit for purpose because its quality has diminished or the original understanding was so far removed from the real requirement that has since become better understood. This is the point I'm trying to make and that people use "refactoring" incorrectly for this exercise.