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