Bed-Time Discussion on the Best Debugging Advice

Question

Recently I inherited a major piece of software. The original model of the software was lost over generations of programmers working over it (though even the "original model" looks a lot broken). There is no unit test in the code. Fortunately, I do not have a requirement to be backward-compatible (oh that would be worse than hell!). I am taking an approach of selective-forceful, selective-restricted approach to refactoring the code. In the past, I've burnt my hands often with trying to change a lot at the same time, and still consider myself tending to do that.

At one occasion, I also solved a bug after a long time of remaining stuck. From that experience I understood that it is important to spend time to find the missing "right hypothesis", rather than keeping trying new things.

I know my next goal should be to create a testsuite asap but currently am inconfident of how to do that. I'd love to use the principles of refactoring dealt within the book "Working Effectively with Legacy Code", but lack the patience and time (or discipline?) to follow the book.

If you would like to provide some debugging tips based on your experiences, please do.

Answer 1

In my experience, to get your end-user support is fundamental.

I'd a similar experience several years ago, when I received a Clipper Summer '87 application to maintain and to make it Y2K compatible. Started as a nightmare: I started to fix some bugs in one place and another piece stop working. After spending some time, I scheduled a meeting with some key users and proposed to rewrite that application.

I rewrote most important features first and had a very close talk with that users every day, which frequently suggest important missing spots. Every week I'd migrate some sample data, so they could have a feeling how about that application was running. I got first version running in about three weeks, and just a small feature set was migrated.

There was a specific report which took 45 minutes to be processed and it ended costing just 5 seconds on newer version. So, that users saw it was a good choice to spend more time and money throwing old code away and starting a fresh version.

I'm aware not every time you can rewrite an application. But to understand what's important to your customers and to make they understand some major changes are in place was decisive to that project success.