At this very moment I am trying to tackle a very common problem at work.
The problem is that the legacy code base I am working with stinks. Some parts when taken by themselves are OK or even pretty darn good. Other parts stink like a garbage dump in August. But thats not the real problem. If it were, then I (we) could just section off the bad areas as best we can, encapsulate them in some non-stench-permeable layer (interface) and not worry about them. We might even find the time to later fix them (unlikely). The real issue is that the stench of the code base is greater than the sum of its parts. Over the past 6-8 years countless developers, each with there own levels of competency, favorite frameworks and different coding styles, have hacked in whatever the business needed. I don't know how much time they spent trying to come up with "good" solutions or what their intentions were, but in any case the end result was smelly.
My problem is one of depth. When making a new change to either some new code that interacts with the old, or to old code directly (the business requirements and initial design of the system dictate that old code must be modified in following years ... the code is supporting a business process that runs in yearly cycles) how far should I go? Do I just follow the smelly path laid out before me and copy what the guy did last year? Do I try and modify what little I understand of the existing design to be better and more adaptable, or at the very least a little more readable? Do I attempt to rewrite the portion I am working on so that it is "good"? If I make a change here, even if its for the better, will it make the code base just that much less cohesive and disjunct? Should I try and just be consistent for consistency's sake?
I am racked with indecision. I am a firm believer in accountability and pride in this industry. Or in pretty much all jobs for that matter. If you are going to do something, you should try your best and whatever happens you should be accountable for your actions. Assuming you try your best and didn't misrepresent yourself along the way, you should take pride in the account. Whatever it is.
The problem is that its hard to take pride in applying a hack. Or even worse, extending a hack that was already there. But there are always time constraints, and project deadlines. Sometimes there isn't enough time to make it "right" and you just have to make it "good enough".
I still have no idea what I am going to do about the particular decision I am faced with at the moment, but I have an 11am meeting I need to get to so hopefully I will have the answer when I get back ;-) Tune in next time when I try and use a A* algorithm to find my sock drawer in the morning (joke, although that might be an interesting project .......).
Thursday, January 3, 2008
How much "better" do I need?
Subscribe to:
Post Comments (Atom)
2 comments:
I've come to a happy medium when it comes to stuff like this. Like you, I want to rewrite everything so it doesn't suck, but you don't have time to do that... So if I can't rewrite all of it, should I just add a hack in to get what I want? Should I bite off a portion of it? If so how much?
I started thinking about these things in terms of walls. Can I wall off the the piece I need to update or add from all the crappy stuff? How much of the existing stuff would I have to change to do that?
It tends to become clear after trying to design the wall if the nature of the current code is going to force me to bite off more than I can chew or not. That is, how close "in" can I put the wall. If I have to put the wall far away, it may not be worth it. But if I can keep the wall close to the thing I'm changing or working on, it probably is worth it. If it isn't worth it, hack it. If it is worth it, wall it off.
In this way parts of the system will slowly get better and you'll still be getting things done efficiently.
I imagine that Josh would point out that this would be the "Agile" approach. At least, thats what I'm beginning to understand.
Any-who, good post. I especially like the part about the stench being greater than the sum of its parts. Too true.
The code's problem is that it was clearly duplicating information that was in the DB in a very unclear manor.
The projects "problem" and/or issue is that the application models a business process that has yearly additions of new logic and code for numerous business "programs". This means that there is very similar logic, but not the same, branded for 2005, 2006, 2007 .... and soon to be 2008.
I ended up putting the "wall" around just the '08 code, but wasn't able to fully clean it up and remove the duplication (the best I could do was make it much clearer what it was doing and a bit more adaptable for 2009...).
I understand why the original developer chose the duplication (taking it out leaves you with some other performance/design issues to tackle) from an implementation perspective, but the result is really hard to manage or modify in any way.
Post a Comment