I first created a set of regression tests . I could now keep the code OK by treating it as a black-box. It had to pass all the tests. The tests took time to run and check, but the approach kept the production system going as modifications were made. It had the added advantage that I did not have to understand the code. This was just as well because I didn’t at that time.

I renamed all poorly named items and inserted comments about what I understood each chunk of code was about. I then began to refactor small pieces of code and add trace outputs. Each separate piece of code had start and exit traces.

All trace outputs followed a naming convention. Now I could now find where in the source code each trace came from. The logs were easier to follow because the first part of each message specified the trace’s location followed by a name and value.

By this time the customer was seeing real progress as their system stabilised and debugging was speeded up.

I finally knew enough about the behaviour of the system to start refactoring the structure of the overall solution and get it into a much more manageable state. By this time I could even give more reliable estimates as to how long changes might take.

Finally, I was able to reflect back to the business what their business rules were and to help them debug their business processes. The tool used was StreamServe.

Using tracing and some simple naming conventions helped massively.

(I was just passing by but thought the above might help someone.)