First off, I wish C#Refactory were available for VB.NET!!!  ARRGHH! 

I've become so enamored of C#Refactory (find it at http://www.xtreme-simplicity.net/).  It's one of those tools you use for a week and realize it's already paid for itself, a slam-dunk.  I've bought $1500 tools that weren't as useful.

If you haven't already been deluged with the notion of "Refactoring", have a look at Ward Cunningham's Wiki http://www.c2.com/cgi/wiki?CategoryRefactoring.

To me, the whole Agile/Xtreme movement is brilliant because it recognizes the gigantic, screaming, pooping pink elephant that's been sitting at every software development meeting since, oh, I don't know, Turing was at Bletchley Park.  Namely:  software development should be an iterative, collaborative, and dynamic process with frequent milestones, heavy ongoing testing, and a "no surprises", "zero defect" mindset.

Anyway, in my Pantheon of Practices That Actually Freakin' Work, I rank refactoring just behind test-driven and automated builds.  I don't believe in just hacking out some procedural code then band-aiding it until it's pretty; I still sit and think things through a bit for overall structure.  But I always paint myself into a corner at some point, and that's were refactoring swoops in.

I love Martin Fowler's characterization of poorly factored code as "smelling".  It does, indeed.

Today I realized I have a Horrendous Smell(tm) in a piece of code I'm working on.  It's the mercaptan of code smells.  It would embarrass Shrek.

I have to add a parameter to a call.  But it's not any call; it's a call that goes from a Winform client, to a web service, to a BLL, to a DAL with a couple of side-trips through verification and crypto layers.  It royally sucks, because I have to touch every layer to accomodate it.  Oh BTW, all the unit tests will have to change too.

Here's the thing:  I'm doing this project in VB.NET, so I can't use C#Refactory.  If I could, this would be a twenty minute job.  As it is, it will take the rest of the afternoon.

Project Apathy:

All this got me thinking, there's a terrible apathy that sets in with programming tasks like this.  It's something you KNOW you can do, in fact it's trivially easy.  BUT, it doesn't "move the ball forward" (god I hate MBA-speak)...but it will break perfectly fine, working code that's been well-tested for its original assumptions.

Faced with tasks like this, I suspect like me most of you get this terrible lethargy.  You write a blog (check, doing that right now), check your email, perhaps surreptitiously sneak off to www.planethalflife.com to check on HL2's latest release-date fairy-tale.

HOW TO BREAK THIS LOGJAM:

Xtreme Programming to the rescue!!  Bust out C#Refactory.  Bust out NUnit.  Tag SourceSafe with a label right now, before you break everything.  Assess the size of the task; break it down so it's achievable before you go home at 5PM today (yes, I practice that part of XP religiously).  Run your NUnits to be sure you're at a stable starting point and...

REFACTOR!  Now you've done it.  Yep, the code compiles but you know it's wrong.  I like to start at the bottom layers; I'll fix the logical problem in the DAL/stored procedures first.  Run the NUnits.  Yep it works.  Move on to the BLL; fix, test, run, DONE.  Now the web service.  Regenerate the proxy classes (I never use the "add web reference", prefer to gen my own proxies and decorate them with handy things like config-driven endpoint URL's).

Lastly, munge the UI.

Check it all in.  Open the BusyBeeBuilder remote control, and kick off an automated build/test cycle to be sure I haven't broken integration either.

OK....enough procrastinating.  I'm going to go fix this code now; an Xtreme-Simplicity guys, PLEASE get me that VB.NET version soon!!