×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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?
Everything is of course relative, but from a business reality
standpoint, the two things that contribute most to the ongoing cost of a
program are bug fixes and enhancements.
If you have already rewritten some programs to new standards and you
have implemented a decent time tracking system over the years, you can
try to identify the costs of fixing bugs and the cost of enhancements to
this program, and compare that to the costs of the same tasks with a
"newer" program of similar complexity.
That's the best case. After that, you start getting into fuzzy areas,
but it's not that bad. If you think about it, the rewrite is only
justified the program is going to be easier to enhance or is going to
have less bugs, or both. The easier to enhance part is somewhat
quantifiable by coming up with a hypothetical new feature and estimating
how long it would take to enhance the current application, and then
estimate what it would take in the "new" version. Obviously there's a
lot of estimating going on there, but if you're really serious, you
should know enough about the application to be able to make those calls.
Bugs are a bit harder to quantify, but if you can go over the old bug
reports and find ones that clearly are due to the complexity and
unreadability of the code, that can help.
Note that this is all based on the premise that you actually understand
the program pretty well and have at least a basic idea of how you would
rewrite it. Obviously, "I wanna put in subprocedures" isn't going to
give you much basis to justify the rewrite.
Joe
midrange.com
