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