“Hero Mode Refactoring” AKA Enemy Of Brown Field Development

What do I mean by “Hero Mode Refactoring”?  We’ve all worked with code that wasn’t easily made testable. Most of the time we see a big ball of mud and have no idea where to begin. Sometimes however we have an epiphany, a _great_idea_ , a “cold fusion” moment (that ends up being poignant in so many ways). 

Filled with the excitement of our vision we dive head long into our work, replacing concrete classes with interfaces, removing big swaths of redundant code, and in general making changes you should only make with a an already unit tested code base.  Before we know it, 5 things are broken in weird ways, and it now takes us days of manual verification to figure out what works and what doesn’t.  That is hero mode refactoring at its best.

This situation reminds me a great deal of the difficulties I had with getting back in shape. I was a pretty decent athlete in my college days, but the real world had other ideas. Years later I tried to get back in shape several times, each time I tried my hardest right off the bat, and most of the time got injured in the process.  It wasn’t until age had given me some patience that I was able to actually get back in the gym in a consistent way. I had to work on the areas I could handle in a gradual way, instead of going 100% day 1.  I wasted years trying to get to 19 year old me in a month, but it only took me 6 months going the gradual way to be in decent shape.

So too our codebases will behave if we try and go full out on day 1. That code didn’t get that way overnight, and usually cannot be fixed overnight.  Take a “siege” mentality into your code maintenance and realize this is a battle best fought gradually.

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Ryan Svihla

I consider myself a full stack polyglot, and I have been writing a lot of JS and Ruby as of late. Currently, I'm a solutions architect at DataStax
This entry was posted in BDD, Brownfield, TDD. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Christopher Harris

    Great comparison. An additional thought: We didn’t gain that 20+ pounds in one month, likewise our code although not perfect, starts out pretty well and deteriorates over time. It’s these small refactorings that will improve the ‘healthiness’ of our codebase.

  • http://nomorehacks.wordpress.com/ No More Hacks

    Oh yes. I’ve done it and regretted it.
    http://nomorehacks.wordpress.com/2008/04/04/today-was-a-good-day/

    I call it free-solo refactoring, like the suicidal climbing style (http://en.wikipedia.org/wiki/Free_soloing)

  • Alex Mancilla

    I think It has different names and faces but goes to the same, sometimes to much refactoring my get us intoxicated with our own code. I just happened to me last week, I found some repetitive code for data access and consuming web services, and I thought I can optimize it and replace and cut a bunch of code here and there, well I went too far, and yes all the sudden there were five or six things no longer working, then I said, stop! just go one step behind, what about just getting all the data access, In good shape this time, Then I rolled back my changes, and focus only on the data access, I left the web services for a next refactoring session. And It goes better, at least after 1 day I get the data access in shape (most likely) and nothing is broken.
    So bottom line, Yes I agree go gradually on refactor, and when you feel your getting injured by the amount of effort ,slow down, or even step back.

  • http://lpgupikivkuy.com/ yalhlplm

    JpzgB2 yfvllytpxsdb, [url=http://ybcocabucgii.com/]ybcocabucgii[/url], [link=http://vikhffzkrufu.com/]vikhffzkrufu[/link], http://mapdgjuowypy.com/