4 ms·

Realistically If there were detailed specifications, they were hard copy print-outs from the 80s that are probably no longer readable, and undoubtedly were thro

Realistically If there were detailed specifications, they were hard copy print-outs from the 80s that are probably no longer readable, and undoubtedly were thrown away in the intervening decades. Many of these old systems rarely require changes in most modules. (As in, of the hundreds of thousands of lines in the system, many subsections just never get touched). This means for the the parts that never get touched, there is a negative return on investment for rewriting them, so there has to be a correspondingly larger positive return on investment in the higher churn parts to make a rewrite worthwhile. Most of the times when this is studied, the return on investment from the rewrite is either tiny or net negative from this effect. Ah you say, then just rewrite only the parts that tend to change a lot, and leave the other stuff as COBOL. That sounds good right? Except that generally the cross language interop code needed becomes an absolute nightmare. I've dealt with this in an near ideal enviroment, and it was still a royal pain. This near ideal environment was: COBOL code restricted to just a subset used by the company, which was being translated to C code by the companies own compiler, which allowed for a C-compatible ABI to be defined allowing for surprisingly simple and direct C to Cobol interop. Yet even then the code code was still a royal pain, just due to how COBOL data structures differ so much from the idiomatic data structures for C or C++ code. My code was actually C# code interacting via C++/CLI with some C++ code that interacted with the the COBOL. But the interop code was still some of the worst code to touch.

tablespoon 5y ago
>> I have to admit that I don’t fully understand why COBOL is so difficult to replace. If the systems are so vital surely there is a detailed specification and writing in an easier to maintain language would repay the effort? > Realistically If there were detailed specifications, they were hard copy print-outs from the 80s that are probably no longer readable, and undoubtedly were thrown away in the intervening decades. Or not kept up to date. My employer has some mainframe systems, and when they were built they had technical writers and created pretty good documentation, organized in binders. For the last two decades, at least, these systems have been "legacy" and the company stopped employing technical writers. During that time, they were still pretty critical, but I'm pretty sure no one kept that documentation up to date with whatever changes were made. Also, about a year before the pandemic, we had building reorganization, and a lot of those binders were thrown out during the move. They were kept on several large, neglected shared bookshelves, and I think anything anyone didn't specifically claim was discarded by facilities. The thing with legacy systems is they can be vital, but they also can be neglected. The gamble most businesses seem to take is: "as long as it works, starve it and hope it doesn't blow up on my watch."
- klelatti 5y ago
  This is a key point. At a more organisational level many big firms saw these systems as just a cost to to be minimised and not central to their business and to be invested in. Often maintenance would be outsourced. So now the documentation and expertise just isn’t there.
  - quag 5y ago
    Arguably that’s the difference between tech and non-tech companies: the tech companies embrace such systems, the non-tech companies minimise the cost of the systems.

tablespoon 5y ago

>> I have to admit that I don’t fully understand why COBOL is so difficult to replace. If the systems are so vital surely there is a detailed specification and writing in an easier to maintain language would repay the effort? > Realistically If there were detailed specifications, they were hard copy print-outs from the 80s that are probably no longer readable, and undoubtedly were thrown away in the intervening decades. Or not kept up to date. My employer has some mainframe systems, and when they were built they had technical writers and created pretty good documentation, organized in binders. For the last two decades, at least, these systems have been "legacy" and the company stopped employing technical writers. During that time, they were still pretty critical, but I'm pretty sure no one kept that documentation up to date with whatever changes were made. Also, about a year before the pandemic, we had building reorganization, and a lot of those binders were thrown out during the move. They were kept on several large, neglected shared bookshelves, and I think anything anyone didn't specifically claim was discarded by facilities. The thing with legacy systems is they can be vital, but they also can be neglected. The gamble most businesses seem to take is: "as long as it works, starve it and hope it doesn't blow up on my watch."

klelatti 5y ago
This is a key point. At a more organisational level many big firms saw these systems as just a cost to to be minimised and not central to their business and to be invested in. Often maintenance would be outsourced. So now the documentation and expertise just isn’t there.
- quag 5y ago
  Arguably that’s the difference between tech and non-tech companies: the tech companies embrace such systems, the non-tech companies minimise the cost of the systems.