4 ms·

When I've seen this in other banks it's been difficult to keep the junior devs interested in staying with COBOL. In general they wanted to move to other teams.

nubinetwork 3y ago
I don't blame them, some places would rather maintain their 1960s status quo than port to modern languages. It makes no sense but management is rather resistant to change.
- century19 3y ago
  Oh that's not the case here, management would love to get off these systems. They see the risks with the age profile of developers, staffing issues, and general ageing tech problems. Re-writing these systems in another language is almost not an option. They have been written over decades with countless undocumented projects. They are core systems that work the way the business wants (or is built around, for better or worse), and doing a port would take years 100s of millions budgets and have a very high risk of failure. I've seem smaller/non-core mainframe systems ported and they have been years delayed and plagued with issues, where it is very difficult to specify what is wanted other than something that is the same as the systems that is currently there with all it's weird corner cases.
  - nubinetwork 3y ago
    Gotta rip the bandaid somehow. Even if it's not perfect, at least it would be more maintainable than COBOL.
    - deleted 3y ago
      [deleted]
    - grugagag 3y ago
      Ripping the bandaid could potentially cause fatal bleeding. Keep in mind these stacks are calcified on a lower layer of stack and other higher ones depend on.
      - mschild 3y ago
        Sure, but the situation isn't getting any better. At some point you will have to start paying exorbitant salaries to people that still know Cobol and are familiar with mainframe. Then they'll need probably years to understand and untangle the systems. The sooner you start, the easier it's going to be.
  - jve 3y ago
    I lately read this wise sentence: > “As an example, we knew that the General Ledger capability would most likely not be modernized for a very long time as changes are slow and the module is very stable,” explains Uli Homann, Corporate Vice President in the Cloud + AI Group at Microsoft. “If you were to transpose this situation to modernizing a mainframe application landscape, for applications or functionality that’s unlikely to change, it might mean that you would opt to rehost your existing COBOL, PL/I, or mainframe assembler code using capabilities from partners such as Raincode—and then eventually rewrite those applications piecemeal as COBOL or PL/I programming skills continue to get more scarce and expensive. In the meantime, though, rehosting existing code buys you time and frees-up cashflow to focus on more pressing or important modernization projects.” https://customers.microsoft.com/en-us/story/1636062794805219031-dynamics-365-application-modernization-on-microsoft-azure https://customers.microsoft.com/en-us/story/1636062794805219...
  - GoblinSlayer 3y ago
    If you don't know what the system does, then you can't modify it, because you don't know if modification broke something.

nubinetwork 3y ago

I don't blame them, some places would rather maintain their 1960s status quo than port to modern languages. It makes no sense but management is rather resistant to change.

century19 3y ago
Oh that's not the case here, management would love to get off these systems. They see the risks with the age profile of developers, staffing issues, and general ageing tech problems. Re-writing these systems in another language is almost not an option. They have been written over decades with countless undocumented projects. They are core systems that work the way the business wants (or is built around, for better or worse), and doing a port would take years 100s of millions budgets and have a very high risk of failure. I've seem smaller/non-core mainframe systems ported and they have been years delayed and plagued with issues, where it is very difficult to specify what is wanted other than something that is the same as the systems that is currently there with all it's weird corner cases.
- nubinetwork 3y ago
  Gotta rip the bandaid somehow. Even if it's not perfect, at least it would be more maintainable than COBOL.
  - deleted 3y ago
    [deleted]
  - grugagag 3y ago
    Ripping the bandaid could potentially cause fatal bleeding. Keep in mind these stacks are calcified on a lower layer of stack and other higher ones depend on.
    - mschild 3y ago
      Sure, but the situation isn't getting any better. At some point you will have to start paying exorbitant salaries to people that still know Cobol and are familiar with mainframe. Then they'll need probably years to understand and untangle the systems. The sooner you start, the easier it's going to be.
- jve 3y ago
  I lately read this wise sentence: > “As an example, we knew that the General Ledger capability would most likely not be modernized for a very long time as changes are slow and the module is very stable,” explains Uli Homann, Corporate Vice President in the Cloud + AI Group at Microsoft. “If you were to transpose this situation to modernizing a mainframe application landscape, for applications or functionality that’s unlikely to change, it might mean that you would opt to rehost your existing COBOL, PL/I, or mainframe assembler code using capabilities from partners such as Raincode—and then eventually rewrite those applications piecemeal as COBOL or PL/I programming skills continue to get more scarce and expensive. In the meantime, though, rehosting existing code buys you time and frees-up cashflow to focus on more pressing or important modernization projects.” https://customers.microsoft.com/en-us/story/1636062794805219031-dynamics-365-application-modernization-on-microsoft-azure https://customers.microsoft.com/en-us/story/1636062794805219...
- GoblinSlayer 3y ago
  If you don't know what the system does, then you can't modify it, because you don't know if modification broke something.