Software Philosophy - Refactoring Paradox

Another day I was talking with a colleague about the Interpreter Pattern to solve a implicit language problem. Martin Fowler describes a pattern called Query Object to solve this, which is a interpreter focused on database queries.

Refactoring as the best technique

Code Refactoring is, after learn a language, is the most important thing a developer should know. Refactoring is what really reveals what soft means in software. When building a bridge is practically a one shot, once the foundations are ready you can´t improve them as the construction continues. But with software, you usually improve the foundations as you go, mostly because nobody knows where is the other side of the bridge you are building.

Refactoring paradox

Refactoring has a implicit paradox, you have to factor before refactor. You can't, at first, use such good technique without make mistakes a priori. This fact became clear when we had to refactor a code which was growing to cope with combinations of SQL queries. In the book Refactoring to Patterns this problem is described as Replace Implicit Language with Interpreter.

But if you think about it you have to code the queries and many methods to see what implicit language is taking form. Probably you will not foresee the language, if you try to predict such implicit language many anti-patterns and bad practices will rise, such as Premature OptimizationYAGNI and etc. For this particularly problem, if you try to code the solution at first, you will end with a criteria object and without any value from your code since this generic approach already exists.

Frederick Brooks in the Mythical Man-Month wrote about the Pilot System. This idea implies the construction of a throw-away when coding a new system. He argues that if you not plan you will throw-away anyway. This idea agree with the refactoring paradox, you can´t refactor before factor and there´s no need for refactoring a good code, but the chances to get it right on the first try is minimal, I will make a bold statement that is impossible to get it right on the first try.

Conclusions

  • Brooks is right, plan to a throw-away, you will anyway, at least part of the code will be replaced.
  • Don't fear rewriting, is part of the job, put it on your estimates.
  • Software is soft don't try to make it hard, is unnatural.

That's it.

Published in Sep 16, 2009