I've followed the "Agile series" articles by MartinS in the UT magazine.

The most recent article has the statement "The Agile idea is that code should be kept as clean and flexible as possible, and then, each time that corruption starts to happen - and it happens very frequently if you're not very attentive - you have to improve it. And always remember that Refactoring means improving the code that already works, not fixing any function. ".
In essence the current article, as well as its predecessor, constitute a license to change any code that you don't like and I think this is absolutely wrong-headed!

What is preached in these articles certainly is a programmer's dream, but it is my contention that it really is a project manager's nightmare.

Except in extreme circumstances it is never (repeat: NEVER) sensible or practical to "refactor" running production code. Never!!! The "extreme circumstances" would only include very poorly written code that is extremely difficult to amend for the purpose of either fixing a bug or adding some enhancement.

In the near universal case of an adequately written (coded) application any bug fixing or enhancement addition is best done by amendments within the existing code. Of course new methods/functions/form/reports/etc can be introduced in such situations.

With an adequately coded application "refactoring" can only buy you trouble with a capital "T".
The "decision" to "refactor" brings with it necessity to perform much more stringent unit testing as well as absolutely thorough system testing. I contend that in most cases the refactoring programmer will not develop the required unit tests to adequately prove the new code. Confidence that the new code is functionally equivalent to the old code will result in minimum testing rather than complete testing.
Refactoring for the sake of refactoring results in either extended development time or extended test time, and neither is good from the client's perspective.

Of course the temptation to "refactor" is great. Virtually any code done by someone else is difficult to work with. We all have our personal foibles when it comes to coding "style". And there can be no doubt that rewriting code is a legitimate way to learn just what the code is doing.
But the functionality of code *can* be learned by carefully reading the code too. Sure, this may be more difficult to do if the code at hand uses lots of multi-compounded IF statements that you detest, but it is totally unreasonable to rewrite code simply because it aggravates you personal sensibilities. After all, why wouldn't the next person charged with fixing/enhancing the same code not also feel the need to refactor because of his distaste of your style?????

To me this blessing of refactoring - which really is on a willy-nilly for-whatever-reason basis - is a delight for programmers who love to code and feel that their own coding style is the only good one, but it is very bad medicine for delivering anything on time and within a reasonable budget. It is a rare case indeed where you will be the first and only programmer of an application, so you will be much better off developing the skill of reading other people's code with a view to amending it rather than reproducing it in your own style.

Comments?