3 ms·

It might not even be an issue of training COBOL programmers. I'm aware of more than one large-scale legacy system that people "somehow" lost the source code for

by groby_b 13y ago

It might not even be an issue of training COBOL programmers. I'm aware of more than one large-scale legacy system that people "somehow" lost the source code for. Which means fixing bugs means disassembly, hot patching, and keeping your fingers crossed. And if you're lucky and the place is incapable of learning, they'll then lose all documentation for the patch, too. Fixing anything is a nightmare. On the upside, if you can stomach it, there are nice consulting fees to be had. (I'm not aware if the Pentagon lost source code - my experience is with civilian systems)

derefr 13y ago
> Which means fixing bugs means disassembly, hot patching, and keeping your fingers crossed. This sounds like something with extremely high overhead, that would benefit from scale. That is to say, instead of trying to reverse-engineer and patch each module every time you need to make a change, just: 1. run the entire project through a decompiler, making sure that each generated code file on its own recompiles to something that works when linked back together with the rest of the existing modules; 2. and then use that decompiled result as the new codebase, and start refactoring.
- sliverstorm 13y ago
  Who knows how big the program is? Perhaps it can reach a size where refactoring is just way more expensive than patching as needed.
- groby_b 13y ago
  In a reasonable world, yes. In a world where IT is a cost center, this is what happens: 1) People work around it as much as possible. 2) When the pain is unbearable, you bring in a high-priced consultant, because your engineers say something about "recompile" and "refactor". Which you as VP don't understand, are scared of, and are not willing to spend the money on. 3) The consultant puts in a week or so to hack things together. It's much cheaper than the recompile/refactor thing, and so you as VP are a hero to your bosses. 4) Since the consultant is paid hourly, documentation seems kind of pricey. Let's skip that. 5) Lather. Rinse. Repeat. I wish this was just Dilbert, but in quite a few companies, that's reality.

by groby_b 13y ago

derefr 13y ago

> Which means fixing bugs means disassembly, hot patching, and keeping your fingers crossed. This sounds like something with extremely high overhead, that would benefit from scale. That is to say, instead of trying to reverse-engineer and patch each module every time you need to make a change, just: 1. run the entire project through a decompiler, making sure that each generated code file on its own recompiles to something that works when linked back together with the rest of the existing modules; 2. and then use that decompiled result as the new codebase, and start refactoring.

sliverstorm 13y ago
Who knows how big the program is? Perhaps it can reach a size where refactoring is just way more expensive than patching as needed.
groby_b 13y ago
In a reasonable world, yes. In a world where IT is a cost center, this is what happens: 1) People work around it as much as possible. 2) When the pain is unbearable, you bring in a high-priced consultant, because your engineers say something about "recompile" and "refactor". Which you as VP don't understand, are scared of, and are not willing to spend the money on. 3) The consultant puts in a week or so to hack things together. It's much cheaper than the recompile/refactor thing, and so you as VP are a hero to your bosses. 4) Since the consultant is paid hourly, documentation seems kind of pricey. Let's skip that. 5) Lather. Rinse. Repeat. I wish this was just Dilbert, but in quite a few companies, that's reality.