http://www.perlmonks.org?node_id=494777


in reply to COBOL to Perl

Each time I have been involved in a massive change-language operation, the rule is to throw away the old code, and write new code from scratch given the input, the desired output, and any other specification needed. It's faster, more reliable, and produces higher-quality code.

The one program I wrote by doing a direct translation was the only program that had to be rewritten from scratch after my co-op job was over. Everything else I wrote was still working when I went back to talk to my old boss 4 years later.

That was ForTran to C. Since then, I've converted stuff from shell to perl, and been involved in rewrites from C to Java - and each time, we looked at the old program from a user's perspective, decided what we wanted to keep, what we wanted to throw away, and looked at the code itself as little as possible.

Replies are listed 'Best First'.
Re^2: COBOL to PERL
by Anonymous Monk on Sep 26, 2005 at 17:52 UTC
    Each time I have been involved in a massive change-language operation, the rule is to throw away the old code, and write new code from scratch given the input, the desired output, and any other specification needed. It's faster, more reliable, and produces higher-quality code.

    Odd. In my experience, the main reason old code gets re-written is that no one understands it very well: no one knows the desired output, and any original specifications have long since been lost.

    Re-writes tend to involve a lot of code deciphering, followed by a lot of parallel testing. The second re-write (the one that gets done when the system is fully understood) never really happens.

    That was ForTran to C. Since then, I've converted stuff from shell to perl, and been involved in rewrites from C to Java - and each time, we looked at the old program from a user's perspective, decided what we wanted to keep, what we wanted to throw away, and looked at the code itself as little as possible.

    All too often the user perspective is: "do what you want, just don't break anything. No, I don't know everything that happens with the system, and I don't want to. Just don't break anything; ever! Touch as little as possible, and don't change a thing, or we'll need retraining!"

    The first task, identifying all the business rules that need to be encoded, almost never happens, because we have a "working system", with all the rules encoded in the old program. So, regathering of rules never happens; because management thinks it's a waste of time.

    They get what they pay for. :-(
    --
    AC