4 ms·

I’d be curious to know how we’re defining “overpaying” here. These companies have effectively accrued 50+ years of technical debt (they could have migrated off

I’d be curious to know how we’re defining “overpaying” here. These companies have effectively accrued 50+ years of technical debt (they could have migrated off COBOL decades ago). Meanwhile, based on my limited experience with these industries, I’d be surprised if they even offer market rates to new hires.

nobodyandproud 3y ago
Let me up the ante. Why do we believe COBOL is yech-debt?
- pixl97 3y ago
  Hell, after seeing both kind of applications (java vs cobol) by these bank/financial companies I am of the opposite mind. Those COBOL applications will keep working until the sun burns up or inflation makes the numbers so long they no longer fit in bounds. The java applications they write should fill you with terror.
  - trealira 3y ago
    Why do you say the Java applications at banks and financial institutions so bad? I'm not trying to contradict you or say you're wrong; I just want to know why. Not having ever seen this kind of software, I would assume that the existing COBOL applications are good simply because all the bad COBOL code was probably scrapped decades ago, an example of survivorship bias.
    - pixl97 3y ago
      Survivorship bias is bad if you're making a statement like "All old houses were good because we still see some old houses around". But if you already have an old house that's working it's worth considering survivorship bias if you're building a new house to replace it. That new house is much less likely to survive that bias filter. Getting the new house as good as the old house will likely take you far more time and money than you expected. And the same is with software. For example including outside libraries in your application makes the code much easier to write. You don't have to reproduce functionality. But libraries typically work like kitchen sinks. You may not have wanted a garbage disposal, but your library came with it and for the next X years your application is around you have to make sure that disposal doesn't catch fire. From the security side you have to make sure there is no code interaction with disposal or any of the other 'household' functions its including that you're not testing for. At least in what I do for a living which is in the field to code security reviews (I don't do these reviews myself, but I work with the teams that do), the amount of security issues that get caught in these new applications in a multi round process, at least to me is staggering. It has to be a multi round process as we see the issues being reintroduced we'd call out in previous sessions. Quite often in these larger organizations the programming teams are so unstable that between our first calls and last calls the entire team working on it will have rotated out.
- tobyjsullivan 3y ago
  If there’s a shortage of developers who understand the language, then the team cannot properly understand the application (as per TFA). If nobody can understand the application, it cannot be modified. If an application cannot be modified, its value will continuously decrease with time. That decrease in value, as well as the projected cost of building a replacement, is tantamount to accruing interest on a debt. They could have reduced that debt by moving to functionally equivalent but more commonly taught languages back when their team could still understand the system. It wasn’t necessarily wrong for them to accrue this debt - after all, banks and these monolithic institutions are masters at effectively utilizing debt. However, the practice may have become habitual and it looks like they might be in pretty deep at this point.
  - nobodyandproud 3y ago
    Many systems are obscure or niche, but that isn’t tech debt. What you’re describing is a management and leadership failure. In US tech we have an overabundance of Type A people in it for the money, but there are plenty of smart Type Bs who just want stability and a life, for a fraction of the going SV engineering pay. You have to wonder why the latter is impossible for American companies to achieve.
rabuse 3y ago
So let the market decide their fate, as their outdated crap comes to a halt with no one to maintain it.
exhilaration 3y ago
The answer is India. Just Google India and COBOL, there's tons of schools teaching it. So if Watson doesn't work out for you, IBM is happy to sell you offshore consulting services the bridge the gap! This is all win-win for IBM -- you can can keep your $200 million mainframe service contract or hire IBM to (kinda? maybe?) move you to something more modern.
- nunez 3y ago
  Can confirm. When I was in Hyderabad in 2019, I saw signs for a few schools marketing COBOL and FORTRAN.

nobodyandproud 3y ago

Let me up the ante. Why do we believe COBOL is yech-debt?

pixl97 3y ago
Hell, after seeing both kind of applications (java vs cobol) by these bank/financial companies I am of the opposite mind. Those COBOL applications will keep working until the sun burns up or inflation makes the numbers so long they no longer fit in bounds. The java applications they write should fill you with terror.
- trealira 3y ago
  Why do you say the Java applications at banks and financial institutions so bad? I'm not trying to contradict you or say you're wrong; I just want to know why. Not having ever seen this kind of software, I would assume that the existing COBOL applications are good simply because all the bad COBOL code was probably scrapped decades ago, an example of survivorship bias.
  - pixl97 3y ago
    Survivorship bias is bad if you're making a statement like "All old houses were good because we still see some old houses around". But if you already have an old house that's working it's worth considering survivorship bias if you're building a new house to replace it. That new house is much less likely to survive that bias filter. Getting the new house as good as the old house will likely take you far more time and money than you expected. And the same is with software. For example including outside libraries in your application makes the code much easier to write. You don't have to reproduce functionality. But libraries typically work like kitchen sinks. You may not have wanted a garbage disposal, but your library came with it and for the next X years your application is around you have to make sure that disposal doesn't catch fire. From the security side you have to make sure there is no code interaction with disposal or any of the other 'household' functions its including that you're not testing for. At least in what I do for a living which is in the field to code security reviews (I don't do these reviews myself, but I work with the teams that do), the amount of security issues that get caught in these new applications in a multi round process, at least to me is staggering. It has to be a multi round process as we see the issues being reintroduced we'd call out in previous sessions. Quite often in these larger organizations the programming teams are so unstable that between our first calls and last calls the entire team working on it will have rotated out.
tobyjsullivan 3y ago
If there’s a shortage of developers who understand the language, then the team cannot properly understand the application (as per TFA). If nobody can understand the application, it cannot be modified. If an application cannot be modified, its value will continuously decrease with time. That decrease in value, as well as the projected cost of building a replacement, is tantamount to accruing interest on a debt. They could have reduced that debt by moving to functionally equivalent but more commonly taught languages back when their team could still understand the system. It wasn’t necessarily wrong for them to accrue this debt - after all, banks and these monolithic institutions are masters at effectively utilizing debt. However, the practice may have become habitual and it looks like they might be in pretty deep at this point.
- nobodyandproud 3y ago
  Many systems are obscure or niche, but that isn’t tech debt. What you’re describing is a management and leadership failure. In US tech we have an overabundance of Type A people in it for the money, but there are plenty of smart Type Bs who just want stability and a life, for a fraction of the going SV engineering pay. You have to wonder why the latter is impossible for American companies to achieve.

rabuse 3y ago

So let the market decide their fate, as their outdated crap comes to a halt with no one to maintain it.

exhilaration 3y ago

The answer is India. Just Google India and COBOL, there's tons of schools teaching it. So if Watson doesn't work out for you, IBM is happy to sell you offshore consulting services the bridge the gap! This is all win-win for IBM -- you can can keep your $200 million mainframe service contract or hire IBM to (kinda? maybe?) move you to something more modern.

nunez 3y ago
Can confirm. When I was in Hyderabad in 2019, I saw signs for a few schools marketing COBOL and FORTRAN.