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.


David Gibbs wrote:

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?


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.

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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

This mailing list archive is Copyright 1997-2021 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.