6.11.10

Software archaeology

A recent addition to our portfolio of problems is a widely successful application that has been developed by business users to process commission payments.

The application has largely been built by the client over a period of time and continues to be useful to this day. A change in the operational landscape means that  this software won’t scale beyond its current functionality and processing capacity. An upgrade to a full-scale enterprise system is a must rather than a luxury.

As is the case with such organic systems, the entire concepts of the domain are embedded in functions with lines in excess of 1000. You start off following the code and break pointing every significant statement, and before you know it you have lost your bearings. The questions then becomes - “what was the intention of the civilization that built this technology”; with curiously named variables and loops nested to a depth of 5+ deciphering the intention is non-trivial. One has to methodically piece together all the inputs, configuration data and perhaps chant some voodoo spells to get the system to work.

UML Interaction diagrams seem to be a powerful tool in understanding the runtime intention of legacy software, but the subtlety contained in conditional statements can be quite problematic to document. It is tempting to ignore the body of knowledge embodied in the legacy application, but doing so makes the reverse and forward engineering unnecessarily complex. So like the archaeologist sifting through the fossilised remains of a once flourishing civilization, I crack open the IDE and good old NotePad in an attempt to gain understanding.