3 ms·

This misses the point of why COBOL is legacy and bad. Using a language with no real community support and a very small available skilled workforce has massive

This misses the point of why COBOL is legacy and bad. Using a language with no real community support and a very small available skilled workforce has massive negative effects on cost and productivity (i.e., the ability to deliver changes at reasonable cost, in reasonable timeframes, and with reasonable success). You don't want to have something that people could be taught to operate, you want something where skill is a commodity and competition is sprawling. COBOL fails on these parameters, and therefore it is "legacy and bad". You can replace COBOL in the above with any language having insufficient contemporary adoption.

soco 2y ago
COBOL engineers are about the lowest on the pay grade and steadily deliver (when they are involved). Peanuts compared to any fancy consultant invited to draw cloud architectures with unrealistic expectations or timeframes. So this workforce cost argument does not hold water. However, licenses are very expensive indeed, which is why there are migration pathways for COBOL-on-other-platforms. But a migration is much less sexy than a rewrite (AI supported) so there.
- arghwhat 2y ago
  The general consensus around here has always been that you can get paid whatever you want if you're willing to code COBOL by being a specialist consultant. This holds true for any legacy system, whether it's a factory control system, a legacy programming language, an ancient piece of hardware or whatever. That workforce is a small retiree club at this point, with financial institutions panicking and trying to promote COBOL and push it into computer science programs. "Steadily deliver" is not a quality you can blanket assign to a group of people, and sounds more like an excuse for poor performance. The only quality one can assign to a small group of people will be lack of competition, which is purely about numbers, although that itself does not mean there won't be good developers in the group - just that that there is a lack of stimuli to grow the baseline.
_DeadFred_ 2y ago
There are the same number of COBOL devs and embedded driver devs. Guess we better switch hardware away from using embedded drivers.
- arghwhat 2y ago
  Where in the world did you get those statistics from?
  - _DeadFred_ 2y ago
    IBM puts the number of COBOL devs at around 2 million, others around 1 million. Full-time experienced people is placed at around 200,000. Total embedded devs are around 2-2.5 million, but embedded driver devs are a much smaller subset. Hard to find numbers but probably around again 200,000 full time experienced so roughly the same amount.
    - arghwhat 2y ago
      So numbers from the only supplier...? You are making a false comparison. Even if we assume the number is correct, you're making a false comparison - COBOL is a language, "embedded drivers" is a software component. The equivalent to your COBOL number is all C/C++ developers. Looking at some random online statistics like you did, COBOL is at 0.7% usage in 2024 vs. 20.3% for C and 23% for C++. Is that statistic credible? No, but neither is yours, and what matters is that COBOL doesn't. Compare language or language, or component to component. (Not to mention that "embedded driver developer" is not s category I'd ever make - half of what an embedded developer does would be classified as "drivers", and that term is only really used for non-embedded.)
      - _DeadFred_ 2y ago
        Yes. I take numbers from IBM as true. I'm not a conspiracy theorist. As I'm not a conspiracy theorist online numbers definitely give close enough for an online discussion. We aren't talking about legalities of a law, we are talking general conversational understanding. Compare use case to use case, not language to language. You say if XYZ doesn't have developers, it shouldn't be used. Now you are saying 'but for your embedded, other people can be trained up'. Guess what, we can train up COBOL developers MORE easily than embedded driver devs. Your argument doesn't make any sense. By your argument we should not build systems around embedded drivers. I've know embedded driver developers and you are completely wrong. They print money. CISCO had to bring my acquaintance back multiple times because again it's such a niche field and no one could do what he did. Same with my buddy that did washing machines. Same with my buddy that did street lights. It is a small subset that do the drivers. Totally relevant to the discussion of 'Can we afford to be dependant on such a niche field'. And the answer is 100% yes, we can.

soco 2y ago

COBOL engineers are about the lowest on the pay grade and steadily deliver (when they are involved). Peanuts compared to any fancy consultant invited to draw cloud architectures with unrealistic expectations or timeframes. So this workforce cost argument does not hold water. However, licenses are very expensive indeed, which is why there are migration pathways for COBOL-on-other-platforms. But a migration is much less sexy than a rewrite (AI supported) so there.

arghwhat 2y ago
The general consensus around here has always been that you can get paid whatever you want if you're willing to code COBOL by being a specialist consultant. This holds true for any legacy system, whether it's a factory control system, a legacy programming language, an ancient piece of hardware or whatever. That workforce is a small retiree club at this point, with financial institutions panicking and trying to promote COBOL and push it into computer science programs. "Steadily deliver" is not a quality you can blanket assign to a group of people, and sounds more like an excuse for poor performance. The only quality one can assign to a small group of people will be lack of competition, which is purely about numbers, although that itself does not mean there won't be good developers in the group - just that that there is a lack of stimuli to grow the baseline.

_DeadFred_ 2y ago

There are the same number of COBOL devs and embedded driver devs. Guess we better switch hardware away from using embedded drivers.

arghwhat 2y ago
Where in the world did you get those statistics from?
- _DeadFred_ 2y ago
  IBM puts the number of COBOL devs at around 2 million, others around 1 million. Full-time experienced people is placed at around 200,000. Total embedded devs are around 2-2.5 million, but embedded driver devs are a much smaller subset. Hard to find numbers but probably around again 200,000 full time experienced so roughly the same amount.
  - arghwhat 2y ago
    So numbers from the only supplier...? You are making a false comparison. Even if we assume the number is correct, you're making a false comparison - COBOL is a language, "embedded drivers" is a software component. The equivalent to your COBOL number is all C/C++ developers. Looking at some random online statistics like you did, COBOL is at 0.7% usage in 2024 vs. 20.3% for C and 23% for C++. Is that statistic credible? No, but neither is yours, and what matters is that COBOL doesn't. Compare language or language, or component to component. (Not to mention that "embedded driver developer" is not s category I'd ever make - half of what an embedded developer does would be classified as "drivers", and that term is only really used for non-embedded.)
    - _DeadFred_ 2y ago
      Yes. I take numbers from IBM as true. I'm not a conspiracy theorist. As I'm not a conspiracy theorist online numbers definitely give close enough for an online discussion. We aren't talking about legalities of a law, we are talking general conversational understanding. Compare use case to use case, not language to language. You say if XYZ doesn't have developers, it shouldn't be used. Now you are saying 'but for your embedded, other people can be trained up'. Guess what, we can train up COBOL developers MORE easily than embedded driver devs. Your argument doesn't make any sense. By your argument we should not build systems around embedded drivers. I've know embedded driver developers and you are completely wrong. They print money. CISCO had to bring my acquaintance back multiple times because again it's such a niche field and no one could do what he did. Same with my buddy that did washing machines. Same with my buddy that did street lights. It is a small subset that do the drivers. Totally relevant to the discussion of 'Can we afford to be dependant on such a niche field'. And the answer is 100% yes, we can.