Refactoring is not free (so defer it)

Paul Gielens has an interesting post discussing the cost of refactoring and deciding when to do so.  I agree with Paul that refactoring is certainly not free and is in fact a very expensive process since it lacks one of the central benefits of Test Driven Development - knowing when you are done!  The process of refactoring is very subjective and it is easy for a pair to spend extra time tweaking things with "Introduce Base Class", "Extract method" and "Introduce explaining variable" until it is just right.

Refactoring doesn't provide any direct business value to the customer and as Paul hints you only get the payback for refactoring when that area is revisited.  It seems to make sense to defer the refactoring until that change is necessary.  I have talked about this before as WhenRefactoringIsYAGNI.  You get to push on with further features instead of the refactoring and that may be OK because you may never need to visit that code again.  Hurrah!  You have saved your customer time and implemented new features.  If you ever do revisit that code then:

  1. You have the same (and potentially more) unit tests to help you refactor it.
  2. You will be looking at it with more knowledge of the system (the best time to do something is the last possible minute it can be done, since you will have the most information possible about the situation - this is usually applied to business decisions but is still relevant here).
  3. You will also be looking at the problem with fresh eyes having not just spent a long time developing the functionality.  (this could be a plus or minus depending on your perspective)

Our practice is to typically defer large refactorings until that area of code is revisited and will just put in a TODO tag in the meantime.

Jonathan Cogley is the CEO and founder of thycotic, a .NET consulting company and ISV in Washington DC.  thycotic has just released Thycotic Secret Server which is a secure web-based solution to both "Where is my Hotmail password?" and "Who has the password for our domain name?".  Secret Server is the leader in secret management and sharing within companies and teams.

 

3 Comments

  • Thanks for the link!

  • "Our practice is to typically defer large refactorings until that area of code is revisited and will just put in a TODO tag in the meantime."



    Large refactorings are only necessary if you deferred *small* refactorings for too long. As small refactorings are much easier and less risky to do than big ones (and are actually part of the TDD process), I prefer to do refactorings as early as possible, when they are still small.

  • But there are guidelines to when you are done refactoring:

    - when there are no duplications

    - the code expresses your intention



    And I fail to understand why refactoring doesn't provide business value. I use less time to refactor something I understand now, than something I will forget the next week or month. Agreed, I will know more of the domain in the future, but if my code is a mess at that time, I am wasting time while I relearn the code.



    I always refactor. I also refactor spikes, prototypes and any other kind of throwable code. I do it because of the practice. Each time I refactor I get better, and spend less time doing it in the future.



    I used to think I was done the moment my tests pass. I kept thinking that until I got burned: Suddenly I discovered that many seemingly small changes broke many tests and required changes in too many places. That is definetily negative business value, because I have to both relearn messy code and spend my time in unrelated classes.



    If you should happen to mean big refactorings are YAGNI, I am with you. Small refactorings, however, is a small fraction of the total developing time.

Comments have been disabled for this content.