Re: Fix or rewrite?

David Gibbs wrote:

Mike Cunningham wrote:

If you can't justify it, don't to a total rewrite. Instead, as each
new fix comes along, spend some time bringing it up to modern specs.

Yeah, problem is, some of the things I would consider as basic to a rework effort would be using procedures ... but programs that are compiled with '*DFTACTGRP' can't use procedures. Converting a program to use a non-default activation group is trivial, but it would need to be heavily tested. This is where the justification problems come in.

You nailed it. If you have a good automated test suite you can make big changes and still be confident that you didn't break anything within the program, and that interrelationships between programs are intact, too.

It's been my experience that a rewrite is almost always worse than gradual, incremental improvements. All that strange cruft in there is almost certainly the result of a bug fix in the past, or an exception to a rule, or SOME thing that hasn't been captured very well in a requirements database. When you're done with the rewrite, you'll be spending a fair amount of time re-discovering those lost requirements (my experience) which will result in upset end users.

It's a nasty problem most of us in the 'heritage' space have to work with. I generally call for a re-write only if the code is actually broken or doesn't apply to a radically new business situation. If it's broken, well, it needs to be fixed; users are already upset, so a new code base can be helpful. If you have a brand new business situation, users are more likely to understand the problem, because they'll be living it too.

--buck