Home » Uncategorized

Rewriting Software

9 January 2004 No Comment

I’ve done two large rewrite projects and I have been involved in a several smaller ones. I have learned over and over again that a complete rewrite is the most difficult, most risky, and most costly approach.

My current client has a project that was moved from another department into the one I’m working for because of business (i.e. political) reasons. The existing application was written in Perl/CGI/Oracle and might be described as a “hack”. The database schema was not normalized, and they managed security through an archaic scheme of assigning blocks of ID numbers to people. From what little I understand about COBOL, I would guess that this was a COBOL-like strategy. Besides the interface being confusing to start with, it also required every user of the system to learn this complex system of access through magic ID numbers. In short, the system was very procedural, hard to maintain, and unintuitive.

The department I’m in manages most of the Web applications for my client, and they almost exclusively develop in Java. So, somhow, the requirement for taking over maintenance of the project evolved into a requirement for rewriting the entire application in Java. Now, I’m definitely a fan of programming in Java, but this was going to be a fairly costly and lengthy project to undertake, and there was no way that we would have met the deadline.

Despite our disdain for the poor craftsmanship of the existing system, the customer was practically begging us to preserve the system the way it was, because they understood the ID based system well. They didn’t want drastic change. I sat down with a few guys from my department and we layed out the full spectrum of options:

1. Rewrite the whole application in Java, get rid of the ID based security and make the application OO, normalize the database schema.

2. Leave the database as is, rewrite the application in Java, but mimic the existing functionality (exactly).

3. Bring over the existing application as is (in Perl) and deploy it on our local servers.

We chose strategy 3, because all the customer really wanted right now was the exact same functionality that existed. Even though we were happy to come up with many improved and OO ways of reimplementing their existing system, we just didn’t have the time.

We had some discussion about how we would handle things moving forward. If we chose option 2, we would have the same poor quality system, but in a language we could understand. In fact, a good strategy would be to deploy the existing CGI system, then start mimicking each existing function of the system, one at a time, but rewriting it in Java. We could have all incoming requests pipe through Java and let the Java code handle what it can, and defer the unimplemented Java features to the existing CGI application. We would basically iteratively move from option 3 to option 2. Thus, the database and functionality would essentially stay the same.

The nice thing about this approach is that we wouldn’t have to maintain any of the CGI code (as we would if we tried to go from option 3 directly to option 1). After we had all the code in Java, then we could start refactoring code and normalizing the database. At this point we would essentially be moving from option 2 to option 1.

This seems like a solid strategy all around. From a user perspective, small incremental changes to their interface to a system seem to be accepted much easier than an overhaul. From a development perspective, development can be more iterative, less risky, and the cut-over would be easier to manage. And a customer perspective, there is less risk.

Comments are closed.