When refactoring sux

I went head on into a refactoring project knowing all too well what I was getting into. The end result was to move a chunk of code (I call it a chunk of code because there exists no abstract concepts in our project, only blobs of code that loosely relate to one idea or another) into a new package and into a separate project. The overall goal is to refactor our entire project this way such that coarse grained ideas and entities (such as customer, order, or product) become evident.

I guess I should explain a little background about the actual project I work on. In short, I work at a company that sells business software. Our software is not unique in that it does what most business software on the planet does. It supports order entry, inventory management, A/R, A/P, and so on. It does have some pretty unique and challenging requirements however I don’t want to get into that angle of it. Let’s just focus on how similar it is to most software on the market. Our software should be relatively straight foward except that we have some self imposed problems that make everyday development painful. As with many projects in existence there are many anti-patterns that can be seen on the surface code but as you dig deeper it gets… well, it gets worse. You see, our project was histrically developed under the niave assumption that it would run as a typical Java command line application. It was assumed that a CLASSPATH would be set, supplied on the command line to the Java interpreter and execution would then commence. The problems resulting include but are not limited to, heavy object coupling, dependencies on oodles of third party APIs, circular dependencies, you get the picture. In essence our project is just one blob of code dressed in alternating package names which are supposed to provide the illusion of modularity.

With that blob in mind, (…do you have it pictured? Close your eyes and vision a Java program where everything touches everything else either directly or indirectly.) let us get back to my dilemma. I wanted to move a chunk of code, and in doing so I exposed a major weakness in a framework component (and I use the term component very lossely here) responsible for dynamic class loading. Correcting the weakness lead me down a trail of tears that included a major refactoring of said component along with the introduction of some new test cases. (Yaay, unit tests!) None of this was related to anything assigned to me on our project task list but it’s kinda hard to plan for much less chart thins sort of thing. After the major refactoring I embarked on another major refactoring that involved moving several other Java files around in our project. None of these refactoring were even related to my initial goal of moving that chunk of code into a new project and package. So what happened overall was my moving the leg bone lead to my needing to move the hip bone which was connected to the back bone which upset the chest bone that was also connected to the collar bone and, well I think I’ve painted a picture here.

Here’s my question. Why is it that there are several of these gospels of refactoring yet nowhere can I find a handbook of what to do when moving the sofa to the opposite wall causes the roof to fall the hell in? What does the average Joe/Josephine (me) do when he/she wishes to do the right thing in a project that has got it all wrong? How does one turn a dirty shack atop a pile of muddy sticks on the ground into a cathedral palace? Where do you start? I really want to get to my happy ending but I feel like I’m stuck on “once upon a time”! Holla if ya’ feelin’ me…

(The author does not encourage elevated levels of speech typically experienced when one hollers or yells, nor is it the author’s intent to be grabbed, touched, or felt in any physical way. The text “Holla if ya’ feelin me” simply indicates that a comment should be left if you are in agreement with the above topic.)

4 thoughts on “When refactoring sux

  1. Hi Cliff

    I have been reading your blog with some amusement. Not because of your predicament but to the way you word things makes me chuckle. I also appreciate your position, I too have been looking at code and thinking where the hell do you start refactoring this lot of code, to the extent that it isn’t a refactor but more of a rewrite.

    I think that basically I do some small refactoring and try to do any new code correctly but if the spine of the code is crocked what can you do.

    keep up the good blogging

  2. Thanx Hosky,

    My apologies as your comment was trapped in my spam filter. I’m still learning how to drive this crazy thing and hitting speed bumps along the way. Thank you for the compliment. It’s good to know someone out there is listening. I’ve been keeping my eye on your blog too, trying to take some pointers from you so I can get visits from more than just my wife and my John Deer riding neighbor. Regarding your refactoring analogy, if the spine is crooked then no amount of milk or calcium tablets will do. You gotta get in there with precise surgery, break or remove the crooked bone and allow it to heal straight over time. That’s the part that scares me and most surgeons because it’s risky. The patient may never walk again.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s