The program is written in Delphi. Which is why I was hired – I’m a Delphi guy, and before that I was a Turbo Pascal guy. It is the One True Language as far as I’m concerned.
Did I say program? Sorry, I meant programs. Plural. This system is a collection of over 50 different executables. A couple run client side, the rest on the server. When I first realized this, my brain seized up for a few minutes. Now, after working with it for a year, I have to agree it was probably the best approach to the design.
The software is essentially a vertical market document management system. Some users create the documents, other users proof them, still others sign off on them. Different kinds of documents move throughout the system in different ways, going from queue to queue based on configurable rules. Complete documents get assembled in various ways depending on their destination – email, faxing, local printing, remote printing, etc. It’s terribly complex, by necessity. Having various operations handled by different programs means that if one part gets hung up, the rest of it will generally continue to function.
Fifty programs might, perhaps, be just a bit excessive. From my perspective, coming in and taking over a system that someone else designed, it can be very difficult to determine which of the individual programs does what, or to track down where a bug is occurring.
All of these programs share a lot of common code, which is both a blessing and a curse. On the plus side, when you make a change in a common unit, that change will flow through to all the programs that use it. But on the minus side, when you make a change in a common unit, that change will flow through to all the programs that use it. In theory the common code is a good idea as it simplifies maintenance. In practice, so many things have been poorly hacked into the code over the years that the shared code often becomes a liability, as it makes things extremely unpredictable.
For example, you make a necessary change in Unit A to improve behavior in Program B. But Program C depends upon the code in Unit A to work a very specific way. Now suddenly Program C isn’t working right. Even worse, there is a lot of indirection (even misdirection) in this code, so we may not even know that Program C was making use of the part of Unit A we changed. Until, of course, the customers come yelling at us.
We knew from the start that the code was complex. The deeper we dig, the more we discover just how complex. The chain of references and dependencies between and through unit after unit is breath-taking.