>Hi, Jim.
>
>[Disclaimer: this is a LONG reply]
>
>>I've followed the "Agile series" articles by MartinS in the UT magazine.
>
>First of all, thanks a lot carefully reading the articles and provide feedback. I value feedback wether it is positive or negative, and in this case, I should say it is both. You criticize many of the ideas exposed, but also give me the chance to get back to some points where I could have failed making clear enough.
>
>>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!
>
>Well, the essence of the article is not encouraging yanyone to change code you don't like, but to improve the design of code that is presenting those specific signs of problems approaching, commonly known as "bad smells".
>
>Indeed, I won't suggest anybody to refactor something that don't need to be touched. Refactoring is a practice that you apply once you have a need to change something which is problematic. You first refactor, then make the change. But as I mention in the article, this is not something you do without a net bellow. The net, in this case, is Unit Tests.
>
>>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.
>
>Well, I can witness against that. My work is mostly architecture and Project Management, and I just code a little here and there with the actual developers, for some specific complex problems or importat components, and for the sake of presentations. So I'm quite away from my hard-programmer days.
>
>I do this for several different companies, and of course, results vary. In general, the teams that are more reluctant to refactor things (usually because of upper-management pressures, and generally where I do more training and I have no decision power), tend to have the poorest results in terms of reusability and productivity.
>
>>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.
>
>Well, we are obviously at the opposite sides here. I refactor my own code (which of course, follows my personal style pretty well) all the time. And this is because I never implement something in advance if I don't need it. Then, when I have to extend something in a way that I didn't need before, I first refactor to add this kind of flexibility, and then I extend (by the way, I would write about this later in the series).
>
>>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.
>
>Fixing a bug is another question, because it has nothinig to do with Refactoring. In the case of bugs, the Agile approach is first to write some Unit Tests to actually prove the bug is there, then fix the bug and prove it has been erradicated. Then, if the bug was caused by somehow complex or unclear code, you may proceed to refactor to avoid this kind of bug happening again.
>
>>With an adequately coded application "refactoring" can only buy you trouble with a capital "T".
>
>Not at all. The Refatoring practice is tightly tied with Unit Testing, and although neither of them are silver bullets, they generally increase the awareness over common problems, worst and best practices, and keep you fairly out of major troubles most of the time.
>
>>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.
>
>Well, that would be a poor scenario, and yes, as almost any practice, if you're goofy about it, results will be ugly. If you do proper Unit Testing, though, you tend to catch possible problems well ahead in time.
>
>>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.
>
>Indeed, this is absolutely against my personal experience. The teams I've seeing applying refactoring more consistently and frequently tend to be a LOT more productive than the rest. Teams who resist to improve their code keep having the same problems over and over, and writing the same kind of code hundreds of times. I participated in some projects where the team took the time to refactor the whole application at first and then make all the needed extensions in a fraction of the time it took them previously to simply keep patching the application to introduce even minor changes.
>
>>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?????
>
>Reading the code is the best way I know t understand an application. I always like to have some documentation handy, like diagrams and other artifacts, but I always know that at some poiint, this docs will lie to me. Code doesn't lie, so even if the app is well documented, I read the code to see if everything is doing what it is meant to do. Then, if the code is very hard to follow, but I already invested the time to figure all that out, I feel I may do a good service to the rest of the team by doing a bit of refactoring at a high level to make the code easier for them to understand. And -again, when properly done- I find that this could really boost productivity from then on.
>
>>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.
>
>I beg to differ. After more than twenty years, dozens of different teams and projects, and gazillion lines of code in many different languages, my personal experience is that the teams that have more chances to deliver on time and budget are the ones that care about the quality of the design, the flexibility of the code, and relies on loooong sets of automated tests. At first, every time I teach developers to write unit tests, they all tend to think that I'm joking: "So are you going to spend your time writing 100 lines of test by every 10 or 20 of production code? This is a toal waste of time!".
>
>Once they get used to it, they start to recognize that they in turn produce code faster than ever before, which grows stable and remains stable, and that they spend less and less time debugging, fighting over changed interfaces, getting stucked for hours in complex problems, etc.
>
>Getting now to a point that I think Walter Mester brought in this thread, of course, this is not something that you can just throw to a team of unexperienced developers and let them handle on their own. You need one or two a bit above average to drive things at first, or some external consultant to help a bit in the begining. But all these practices are supporting shared knowledge and resources (and that's why pair programming, common ownership, TDD and the rest work so well togheter). One of the most important side-effects of Agile in general and XP in particular is that they really improve developers from a professional standpoint. Yes, there are always some lost cases, but I've seeing incredible transformations over time, in most cases.
>
>Finally, I'm glad that you don't take my word for granted. I really won't want anyone doing that! That's why I always include ample bibliograpy at the end of each article, and also why I plan to keep the series going for quite some time. There are still many, many things to talk about. I hope that at some point you could find some valuable practices and get closer to see for yourself the benefits of an Agile mindset, even if it may not work on your personal case.
>
>Best regards,


Thanks for the response, Martin