Legacy Response

I can never decide if I should respond to comments with my own, or with a new post.

I guess since this response will be more than a few lines, I will post it.

In response to Josh's comment, I agree totally. 6 is pretty darn young in the grand scheme of things, but for a J2EE application that's decently old (given the frequency with which frameworks and designs pass us by, and it looks like the developers tried to push whatever was the star at the time). At my last client, we were replacing a billing system that was installed before I was born and my job was to write the code to integrate the brand new COTS system with a claims system that was equally old (mainframe). I didn't have to work with any OLD code, but our team did have to work to try get the information that was stored in it out somehow and verify that the information we were getting was what we thought it was.

From what I have seen and understood so far, the real problems rest around the following:

• The original design(s) don't scale well to the business needs - Is a marketing application and each year they have new marketing programs that they need to be able to work with. Each program, each year results in new code being written by a mix of copying, reuse and extension. Depending on whoever was sitting at the PC at the time.
• Turnover of personnel and contractors has resulted in losses of knowledge and inconsistent practices.
• Over the past few years (at least), little attention was paid to good design or doing what "should" be done - New code was written and old code patched with only the current issue in mind. No time was spent deciding if the decisions were good going forward, just to if they fixed the bug they business was complaining about.
• No unit testing (or repeatable testing of any kind) was done - without this, no one could be sure what they changed wasn't breaking code somewhere else so instead of fixing the real problem, each year developers had to redo the work already done just to change one parameter.
• As new code was added to support the current year's programs, the old code could not be removed - the business occasionally wanted to rerun reports of previous year's data, or make small changes after the fact. This resulted in large amounts of code being pulled along for the ride, possibly breaking with every future change, but never being tested until it was needed.
• Rinse and repeat.

As a small sample of what I am dealing with today .... we are having problems with creating our last '07 reports. The code to support the generating of our reports (very basic) has an OK design currently. A report servlet uses a reportManager and an XSL style sheet to generate the report. The reportManager defines the collumns to be displayed and generates the XML data. Pretty simple eh!?

Well, it starts to go downhill when you find out that the latest ReportManager code is 1 of 3 "base" implementations of the required interface. Oh, and random years use random report managers following no discernable pattern. Oh, and each does things a little different and requires a little different information. And, NONE of them allow you to aggregate data from more than one source, OR define formatting for the collumns, OR generate totals and ALL force you to duplicated report information in around 3 places.

You might be saying to yourself, it sounds like those are new requirements, and you can't blame them for not knowing what you will need later! And you would be somewhat right. I wish they would have designed there code a little more object oriented so that I could plug in new things and add new features without breaking anything but they didn't. And thats one problem.

The real problem is that these "new" requirements have been around for years! And what did the previous developers do? They extended whichever reportManger they happened on first, and then proceeded to override 95% of the logic there, redoing the work that had been done, and hacking in the new requirements. Next year? Did it again!

So I am left with the choices of:

1. Do what they did last year, rewrite a ton of stuff (or better yet blindly copy without understanding) and hope that I am not here when they do their '08 work.
2. Hack on the "latest" report Manager code and try to add this functionality into its design without breaking anything previously (and not knowing if I did until someone complained)
3. Come up with a new, better design and spend the time to implement it and figure out some way to try and keep people from going back to the old code.

I am hoping for #3 since it leaves the code base better than when I found it .... but will have to see. As always there are deadlines to meet but I think I will be able to convince them of this minor rewrite. In reality, the whole system should be rewritten so that is 90% configuration each year and10% new code only in years where there is really a new requirement that was never thought of before. That would be the day.

Sorry for the ranting. I had the example already typed up.