A /. post today talked about some group from Sri Lanka that tried to measure the 'improvements' from a refactoring project, and noted that a refactoring

  • doesn't make it faster
  • doesn't necessarily reduce lines of code (like that matters)
  • doesn't necessarily reduce resource usage


  • it might improve code maintainability


  • might not improve readability or ease of ability to change

to which I say, "duh?!?!?!".

Proponents of refactoring have never ever said otherwise (unless they themselves are confused on the matter). Code is only readable if it is either simple, or clearly follows design patterns, or is clearly commented and the comments are up to date with the current version of the code. Code is only easy to change when it is readable and when all external dependencies are well known. That last part is a key thing that metrics aren't necessarily able to capture.

A refactoring project, if not refactoring to the right design patterns to address what was wrong with the structure in the first place, is not going to improve it. One must know clearly why the current structure is making a bug-fix or a new feature difficult to implement.

And while some refactorings are 'good' in that they reduce a lot of copy-paste code, others are good because they add code, or add classes (an alternative increase in complexity). Different refactorings have different effects, and are used in different situations.

And as always, if you don't need to refactor, don't. A refactoring is to improve the design, not to rewrite for its own sake.

And there-in lies the great flaw of the whole idea of such a study: you can't measure the quality of a software design. Some things you just have to judge for yourself, based on experience and attention, and no arbitrary metrics number will ever differentiate between a good design and a rubbish heap.

Disclaimer: I hate software metrics.