@lupyuen Doesn't surprise me at all!
Friends in banks have told me of core systems in COBOL that they dare not touch! What saddens me is that COBOL is perhaps one of the easiest programming languages to understand yet none of them have the confidence to try and understand the subsystems they are supposedly responsible for.
As a good friend always used to say "There are programmers, and then there are the so-called programmers!".
@chrism @lupyuen While I agree that a software engineering team needs to have some people who understand all parts of the systems they maintain, I doubt it's *just* lack of confidence. Management may not be giving their engineers time and resources to learn their COBOL systems, even if those engineers know they should learn them.
(I would also push back on COBOL being one of the easiest to learn. Against the landscape of modern programming languages, COBOL is a real weirdo: full of cruft, bizarre conventions, and surprising edge cases.)
@2ck @lupyuen agreed, not just lack of confidence. There's "if it works ... " mentally, for which I have some sympathy.
I suppose also it is also testament to how good COBOL and its programmers were that there systems still running. Would be interesting to see how many Java systems are running after the same length of time.
C'mon, any programmer "worth their salt" could easily devour a COBOL program.
When I think to some archaic languages I have to decipher on inherited systems I have had to look after, even C++ is a walk in the park.
@chrism @2ck @lupyuen
Understanding the language is not the issue. While COBOL may be simple and easy in itself, the real barrier is deciphering the intentions of the original (dead) authors and the "bigger picture". Of course you can understand every single line of the codebase by itself. Understanding a convoluted domain based on a huge codebase with, likely without documentation and of potentially bad quality might not be so trivial.