Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re: COBOL to PERL

by Tanktalus (Canon)
on Sep 24, 2005 at 15:16 UTC ( [id://494777]=note: print w/replies, xml ) Need Help??


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

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://494777]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (5)
As of 2024-04-23 20:44 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found