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