cheong wrote:I managed to silently replace subsystem by subsystem at a time, and one and a half years later the whole system has been straighten out.
My experience with the Big Ball of Mud has been similar to this. Working in the Financial Services Industry, I have encountered numerous Excel / VBA Spreadsheets and Bloomberg VBA / API code that has been put together hap hazardly by analysts and traders in an effort to achieve a near term goal.
I dealt with this by introducing small changes in small modules / classes one by one.
Here is an example.
Some of the trading analytics was in spreadsheets (.xls ) saved on network folders. These spreadsheets had hard-wired links to other .xls spreadsheets. Besides that, there was no control over the changes made to these spreadsheets.
When I had to make a few code changes to these analytics and deploy them properly,
- the first thing I did was to convert all the spreadsheets to templates (.xlt).
- the second thing I did was to create an add-in with menu, that would internally instantiate the templates, so that users don't have direct access to the templates and hence don't make unauthorised changes and bring the setup down.
- the third thing I did was to store configuration information for location of the templates in an xml file, and added functionality within the add-in to browse and set the location for this xml file. I used MSXML to parse the xml file and load it
into a hash table style "Scripting.Dictionary" object in memory.
- finally, I wrote a .vbs script for deployment of the new analytics, which would take an environment as parameter (ex DEV or QA or PROD) and according set the xml file within the add-in before copying it over to the user's local add-ins folder.
