Monday, December 27, 2004

Challenges of maintaining an almost 9 year old piece of software

 Originally posted on: http://geekswithblogs.net/meshel/archive/2004/12/27/18566.aspx


This in a sense is just a rant, but also a serious post.

I've been working for this company (still the same one I wrote about before) for the last five years in changing roles, I always had some sort of connection to the web component, and in the past 2.5 years, I have been on the actual dev team of it.

To outline the past roadmap of this application, lets just say that it started as a demo. which is the worst mistake that was done here. Why? because when you develop something as a demo/poc/ just for a show, the code behind looks exactly like that.

At the beginning it was developed on Access database (?!?!?!) this was supposed to be software that sold to enterprises - and believe it or not, it was sold... The web application itself was created as the worst spaghetti code possible, with ASP, VBSCript, HTML, SQL, Javascript all mixed up on innocent .asp pages. As I said this was designed as a demo by people not very knowledgeable of Web development - and it looks it.

Lets continue along memory lane.

Then came the next version (this is more than two years after the beginning), support for running the database on SQL server was added (notice added - you could still work with Access). Of course since there were budget restrictions (I wasn't there yet, but I can guess) - they couldn't re-write data layer (remember it was all spagheti code) - and since everything needed to work, the database scheme on SQL server, was essentially the same as the one on Access. So no SPs, no Foreign Keys - nothing... Same badly designed tables and views.

Here comes the next version, I already worked in the company but not on the team. A huge effort to modernize the software (got its own major version). Here there was a newer team. the concept of COM for business and Data layers (the three tier model) finally was implemented, but again - only for the newer features. again because there was no time and not enough money. From then on development is done primarily in VB DLLS, but still some is implemented as spaghetti code in ASP, and of course no re-writes are being done on old code, unless a bug is being reported. Not to mention that no documentation of any kind is being kept or ever created - you have to go through the entire code to understand what is going on. At this stage the QA team leader actually knows better than the Dev team leader how the application will behave at certain scenarios.

By this time it is already quite a large amount of code, with different historical layers, that an archeologist would happily dig through to understand how men thought at prehistoric times, and I inherited it. Of course no one gives me the time to re-write even the most atrocious parts of it (unless there is a serious bug).

By now for each major object, there are at least three ways of creation, all supporting different parameters and sometimes different business logic. I'm always on the crusade to retire old sections and to re-write as much as possible.

As you can understand the main causes for this situation were:
1. a bad beginning
2. unwillingness by management to understand that beginning was bad - and therefore needs some fixing up

Result: code is a mess, adding new / modifying features is real hell - development is much slower, and the chances for mistakes and problems (bugs, backward compatibility, upgrades between versions, security) are greatly enhanced.

We are now planing to migrate the application to .NET - I foresee a nightmare.

No comments: