>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.

"Code smell" is a term that the proponents of Extreme Programming (XP) came up with. "Do the Simplest Thing that Could Possibly Work" is one of their maxims. XP is a specific development process that uses Agile principles taken to "extremes". It's largely a development process for writing new systems from scratch. When going in to "fix" an existing system, it has less applicability, though some of its principles can still be beneficial even in that situation.

The XP founders have a romantic, sometimes flippant, sometimes almost poetic way of expressing themselves about programming. I like their writing very much. In order to get the full benefit, though, it's important to understand that they aren't just goofing around; they are using an elegant kind of "shorthand" to express some very deep concepts.

These folks are at the very top of the heap in terms of programming experience and ability. They are so good that they can intuitively diagnose problem code very quickly. When they say that code has a "smell", they aren't really expressing an off-the-cuff subjective personal opinion. They are summarizing the fact that their years of experience and very high skill levels have allowed them to quickly and definitively analyze the code and detect patterns that pose very real problems for performance, reliability, and/or maintainability. They have this sometimes tongue-in-cheek, sometimes poetic, way of expressing themselves--but they are absolutely not doing anything off-the-cuff or superficially subjective.

The maxim, "Do the Simplest Thing that Could Possibly Work" is fundamental, and it appears, at first glance, to be kind of glib. It's actually the opposite of glib; once again, it's a distillation of all that these highly skilled and creative programmers have learned about how to write high-quality code efficiently. It surely doesn't mean, "Do the Fastest Thing that Could Possibly Work", since in many cases that would be just cutting and pasting code from one place to another. When it comes to refactoring, it means, in your first shot at solving a particular problem, write the least complex algorithm you can think of that passes the unit test. Then, RESIST the temptation to fuss with it further; especially, resist the temptation to think ahead and try to handle a bunch of "what if" situations that may never happen. If, at some future point while you're working on another problem, you find that parts of this other code that you wrote may be relevant to your current problem, then the simplest thing that could possibly work for both problems might be to refactor the existing code into a more generic form. But there are subtleties even beyond this. "Could possibly work" usually means, "could pass the unit test", but it can also mean, "works reliably and safely while passing the unit test". When you get really Extreme, you write a unit test for every boundary condition, so that working reliably and safely becomes synonymous with passing unit tests.

Another XP maxim is "Refactor mercilessly." That doesn't mean, "Refactor endlessly," or "Refactor at the drop of a hat." It means: as soon as you've built up enough user scenarios and unit tests to concretely demonstrate that refactored code will truly be the simplest thing that could possibly work for a particular set of needs, then fearlessly wade in and move stuff around, throw out code, do whatever it takes to arrive at the simplest solution. But overall, the XP folks would never say, "Refactor whenever you don't like something." In fact, they would say "NEVER spend time refactoring until you have objective measures that indicate that it's necessary."

Ken Dibble
www.stic-cil.org