When faced with this problem in times past it has been known to happen
that the rewrite takes a while, is not approved by the TPTB, and is a
huge improvement. "How does that happen?" you ask? As fixes are made,
make them as service programs, sub routines, etc. and then totally
bypass the sections of obnoxious code. As time goes by the obnoxious
code is made irrelevant. After a year or two the old program can be
rewritten in a day or less, since the main work to do will be removing
bypassed code.
fwiw
David Gibbs wrote:
Folks:
Hypothetical question (yes, really hypothetical): At what point do you
decide to re-write a program rather than fix it? And, if the decision
is to re-write it, how do you justify the decision to TPTB?
Consider the following ... you have a program that's about 15 years old.
Written in RPG III, converted to ILE using CVTRPGSRC but never updated
to take advantage of ILE capabilities, and it's a total mess (by fairly
modern standards). Continued modification to the program just seems to
make it worse. The program is not small ... and fairly key to the
system you are working on.
How can you justify a re-write? How can you quantify the cost / benefit
ratio to show that a re-write would be in the best interests of
continued development?
david
p.s. and, just in case someone from my employer is reading this message,
this is truly a hypothetical situation ... although we do have some
pretty old code.
