× 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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.