Guerrilla refactoring, or "How to bring down a totalitarian regime"

Have started a new project at the current contract and I’m muy excited about it. It’s a "legacy" .NET 1.1 app that was upgraded to 2.0 by running the wizard, then left alone. It has a web service created by an architect who appears to have worked with Jeremy Miller before. It returns datasets. Lots of them. There’s a DataDude project created in some CTP version that can’t be upgraded. There is no CI process.

I discovered most of this without cracking open the code. I have since done so and analogously speaking, it is clearly the result of the type of relationship we hillbillies are *very* familiar with.

I’m pretty pumped to dive into it, actually. The CI process is mostly done. The tests are running regularly (2.5% code coverage, woohoo!). Now it’s time to start the grand-scale refactoring.

First, however, we need to go to the customer and tell him, "The architecture of this app is not unlike something akin to roadkill. It compiles only during the waxing phase of the moon and the fact that it runs at all has restored my faith in God. I know you’ve been using it relatively successfully for several months but we’ll need several tens of thousands of dollars from you to refactor large portions of it. When we’re done, there will be no discernible difference to the application from your perspective but we in the IT department will sure feel better about ourselves."

Now I’ve never been able to say "discernible" out loud convincingly and I’m sure as heck not going to imply that I believe in a higher power so obviously, this isn’t going to work for me. Which leads me to a tactic I’ve become quite fond of: Guerrilla Refactoring

Guerrilla refactoring requires some unconventional tactics. Like in guerrilla warfare, I’ll need to ambush the code often. Come at it from an angle it’s not expecting. Do quick, focused skirmishes and get out again before anyone notices (except the code which will be grateful to be liberated from its bourgeois oppressors).

Subterfuge and guile will be my allies. "How long will it take to implement the ‘sync’ function? Four hours, minimum. Change the layout of the form? A good day of coding. You need the text changed on this label? I’d say….three full days. Not including writing tests to expose the bug."

I will bear the brunt of their skeptical, leering eyes for the sake of the common good. No longer will we toil under the totalitarian regime of logic-laden views and hand-rolled data access code. Their armies will *tremble* in fear in the face of my legion of Freedom Fighter Presenters! And the fascists will COWER as I slash at them with my Sword of NHibernate!! JOIN ME, brothers (and to a lesser extent, sisters), as we stamp out the Dictatorship of Duplication and drive a *hammer* through the very heart of hardcodedness!!1!!1!!!!

VIVA LA REVOLUCION!!!!

Kyle the Pacifist

This entry was posted in Featured, Refactoring. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Bill Becotte

    My god, i’ve never read a post that was more spot on than this, i work in an application that this could not describe any better. They want to add new features on top of a pile of crap, i say, well, that will take 6 months, management comes back with but it’s only adding a combo box, i say but there are about 100 bugs in here that you don’t even know exist yet :)

    And as some of you said here, management never wants to know you’re doing work for months that the end user does not see, so i’ll usually add one bell or whistle to the the UI as a token to buy me some needed under the hood time :)

    Great Post

  • http://codebetter.com/blogs/kyle.baley Kyle Baley

    There are some great counterpoints here. Many of which compel me to admit that I’m actually a dirty rotten liar. I’m not refactoring covertly under the auspices of implementing new features. There’s a freeze on now on new features and I’m taking the opportunity to refactor the app in preparation for the new version. I have both the business’s blessing and encouragement for my efforts.

    In fact, I tend to factor refactoring into my estimates, again with full disclosure. “I’ll need to refactor that screen into an MVP first so it’ll probably take half a day to complete.” That sort of thing.

    I was hoping to get at least a month’s posts behind before it was revealed that I’m a fraud but what can you do?

  • Kevin Thex

    Love the humor/spirit of the post, but seems like jeopardizing client trust or donating personal time to the man might not be the best options.

    The concept of technical debt (http://martinfowler.com/bliki/TechnicalDebt.html) can be a powerful tool for these conversations. In “SCRUM in the Trenches”, Henrik Kniberg talks about how velocity suffers when technical debt gets too high.

    True technical debt (not of the “I wouldn’t have done it that way” variety) can be quantified, and can compete with features (or linked to defects) on the next SCRUM sprint. The client can make informed decisions. Nobody should be surprised. Sunlight is the best disinfectant.

  • http://blog.chapmanconsulting.ca Chris R. Chapman

    I agree on this tactic being required where the conditions warrant; however, it does have some downsides for me:

    a) The client never learns *anything* about the cause/effect of hit & run coding that led to the code being in such a terrible state. This goes to what Fowler and others have written about justifying the case for refactoring in the first place – by using the “guerilla tactic”, this necessary restructuring gets swept under the carpet, so to speak. There’s no cause & effect (ie, improved maintainability, stability) that gets communicated to the client. The cause for “refactoring” is lost.

    b) By doing refactorings on-the-sly, you’re signing up for doing unpaid work – period, full-stop. Sure, you can pad the estimates out, a fave tactic of the waterfallers, but eventually the piper gets paid and its with your blood, sweat & tears at 3am.

    Personally, I prefer it out in the open so that the client *learns* something from the experience. It’s painful. You cut corners once, and guess what? It’s a mess and has tripled your costs going forward.

  • Simon Young

    Nice idea! But as “Heh” said, be careful that it doesn’t bite you in your camoflage pants. If another consultant comes along and says they can implement sync in an hour, change the form layout in 2 hours then there may be some eyebrows raised and pointed in your direction. I’d still go gueriila, but with the following exclamation at the start:

    Boss: How long will it take to implement ‘sync’?
    Guerilla: Ack! That code? The code that we need to carbon-date to work out how long ago it was last touched? I reckon it’ll take six hours. But once I’ve finished it’ll be much faster to work on in future and generations of coders to follow will thank you for your vision.
    Boss: Ok
    (Four hours later)
    Guerilla: Great news, it’s all done and look! I found your old false teeth amongst some crufty garbage collection routines.
    Boss: Fantastic, I was looking for those. Excellent work!

    – Simon

  • http://codebetter.com/blogs/kyle.baley Kyle Baley

    You probably know my answer (and knowing you, you’ve done it already): Buy both

  • http://weblogs.asp.net/bsimser Bil Simser

    I’m torn. Both gorillacoder.com and guerillacoder.com are available (at the time of this writing) and I’m just wondering if I should buy them. Oh help me Kyle-Wan, you’re my only hope.

  • http://codebetter.com/blogs/jeremy.miller Kyle Baley

    @Jason: OK, I’m caught up now. Mental note for future: Your readers are usually a step or two ahead of you

  • http://www.codeassassin.com Jason Stangroome

    @Kyle: I’m aware Guerilla and Gorilla are not the same thing which is why I think CodeGorilla.com would have been quite amusing. I can imagine a large monkey sitting at a keyboard refactoring code. BTW, I’m also aware Gorillas are not big monkeys. :)

  • Bob

    God forbid you believe in a higher being. who do u believe in, Jeremy Miller?

  • Heh

    The fun part will be when you screw up a refactoring and then have to explain to your superiors what exactly you were doing when it all went south.

  • http://www.robmulcahey.com Rob Mulcahey

    I’m a huge fan of Guerrilla Refactoring too. It’s usually the best way to improve and introduce new concepts into a code base. I love the phrase “legion of Freedom Fighter Presenters”. LOL

  • The Other Steve

    Sorry, no time to refactor. The Business wants their widget interface implemented by the end of the month.

  • Mike Breen

    great set of posts. glad to see that we can actually have fun with this stuff (some of the talk over at alt.net makes me forget that this is fun). thanks man.

  • http://codebetter.com/blogs/kyle.baley Kyle Baley

    @Jason: That’s an awesome alias. Funny how ten years ago, Code Assassin may not have been a good nickname to have. And I had a conversation about Guerrilla/Gorilla with someone at work. They are *not* the same thing. At the time of writing, GuerrillaCoder.com is available.

  • http://www.codeassassin.com Jason Stangroome

    I’m a big fan of Guerilla Refactoring. It earned me the nickname Code Assassin for VPNing after-hours to apply some well needed code shuffling.

    I’d go register CodeGorilla.com right now but I’ve been beaten to it.

  • Joe

    This is exactly what I’m doing. And it feels great. I’m sure these binge refactorings cant be without thier drawbacks, but man it feels good to see something starting to take shape.

  • Eric Wild

    Kyle,
    How is that “switch to decaf” thing going?