|Problems? Is your data what you think it is?|
First ofall, ++Ovid for bring this (and related) article(s) to my attention. There are many good points in the article. If I could add my 2 cents worth, my first professional programming job involved a major code rewrite.
<reminisce mode>The system was a large batch Fortran application that predicted telephone exchange growth for Australia's (then only) telephone company. The system hade grown over some 10 years to a deck of punch cards you could choke an elephant with, it took about one hour of processing on the CDC Cyber 7000 mainframe, produced some 500 pages of output, and cost $100 (in 1976 dollars) each time it was run. BUT the main problem was political - it was originally written by the engineer who now headed the branch - and even though the staff (his junior engineers) all agreed the program was a "crock of shite", none would publically go on the record and say that, let alone volunteer to rewrite it.
I was there as a three month student engineer, and had no qualms about calling a spade a spade. Besides, it was a good project for someone like me. After spending a week going through the system, and realising there wer efour almost identical programs, each providing the same information in a different format, I spoke wiht the people who used the reports, and found all but one wre thrown out unread.
Step one - new user requirements.
Step two - rewrite, using operating system utilities to do things like sorting, not the primitave substution sort in Fortran.
Step three - test
step four - relase the new version - a fraction of the size, execution time less than 5 minutes, cost under $5.
</reminisce mode>Moral - if your existing system is hopelessly broken, rewrite. Otherwise, try to improve. And only fix one thing at a time.
In reply to Re: (OT) Rewriting, from scratch, a huge code base