I am suspicious about the alleged problem finding people willing to work with COBOL.
Generally, if it's crucial for the business, the lever you pull is increasing compensation until the market responds. That's how you influence willingness. People are willing to do much dirtier jobs given enough money.
"But we need someone who is not only willing but able," they say, meaning they want someone with many years of experience with the language.
These same companies did not invest the time or money to train future maintainers in the language or make it worth their while to accumulate that experience. Guess what happens when you don't invest that money up front? You pay for it dearly later on.
So it's either an impossible situation of their own making, or those elusive COBOL programmers are out there, but companies significantly underestimate how much they really need to shell out for such a specialized skill set.
Either way, I don't think the problem can be reduced to younger programmers wanting to write code in the hip newer languages.
I’m generally pretty amazed at how low the salaries are for COBOL developers relative to the criticality of the systems being maintained, and also how common those legacy code bases are.
This is a microcosm of the "STEM shortage" in general.
Socialize the losses/costs (publicly-funded school), privatize the gains/profits.
That said, there's a different side to the issue, which is that smaller companies do not (and never did) have the resources to train people. There definitely is a shortage of senior management-capable technical people who can lead projects and teams at smaller organizations. This however isn't relevant to big banks and Cobol.
> Guess what happens when you don't invest that money up front? You pay for it dearly later on.
But that's the thing - these companies don't expect to be the ones to invest in these developers over the years, to let them upskill themselves. Neither do other companies. If you look at /r/CSCareerQuestions, you'll find that many of the younger devs are having quite a lot of trouble finding work, very few companies wanting to invest in the start of their careers, since they might as well just look for the more experienced devs out there.
But why is that? Simply because there is no actual guaranteed return on such an investment. A company might as well spend months of their experienced developers' time while making them mentor the more junior devs and invest a lot of resources in this, as well as have more overhead to their development because of needing to spend longer on QA and fixing bugs introduced by these juniors, for them to just turn around and leave when they've gotten the seniority that they desire.
In essence, all of this investment will return this company absolutely nothing and instead will benefit the next company that this developer goes to, which might as well be their direct competitor. Why should companies take this risk, instead of letting other companies do so, train the juniors for them and simply pluck skilled devs from the market when they become available?
I don't condone that approach, but it feels to me like a zero sum game, especially in a competitive market.
I don't have any solutions to offer, since in my eyes preparing devs should be the work of universities AND some other institution after getting their education, that would bring them up to speed to actual industry practices (like bootcamps, but for people with basic knowledge of academia).
Yet, even after getting my Master's, in lieu of such an organization, i simply had to get the practical skills over many evenings and weekends, as well as worked as a developer thanks to one of the companies that did take a risk on me, all while i was also studying. Having to work in the evenings and weekends seems a bit silly when compared with other industries, but with how much churn there is in regards to tech, i don't see alternatives.
Best case scenario is they go broke and decommission the obsolete system, with it being replaced by a competitor using better tech or planning, or leaving an opportunity in the market for such.
"That's how you influence willingness. People are willing to do much dirtier jobs given enough money."
Sort of. I dealt with a large smalltalk system with it's own datastore. Finding smalltalk devs was painful. Training new ones? It was a mess. The dev environments didn't seem to port correctly to modern linux systems - mac? forget it, we could never work out contracts with Cincom Systems to get proper licenses - they would demand us pay a portion of revenue with audit rights (wtf), staging environments were layers of hacks, smalltalk could work on port 80 but making it work with apache/nginx/load balancers was always a mess, smalltalk itself was covered in bugs and would crash for no apparent reason. All new devs knew learning smalltalk was a waste of their future job prospects - they also had no good mentors. Good luck finding things on stackoverflow. The smalltalk contractors that could help would just raise their price so high it turned into extortion (one of them even wanted a portion of gross revenue). These contractors would delete histories, use hand written journals, hide documentation, refused to train anyone, not use version control, quit in the middle of meetings -- and they all were friends - it was a total shakedown. "Just pay them more" never really worked out for us.
The problem is real, for many banks, but it’s not as big problem as it would seem.
I know one bank who does an academy thing, where they bring in graduates, train them for up to two years (with salary) for them to be able to work on the systems.
So, it’s a problem, but they have knows to get around it.
Also. This problem is not isolated to banks. I saw the same kinds of problems when I was in telecom.
Expected earnings is what you think you'll get for this job plus what you think you'll get for jobs further down the line.
Even if a COBOL job paid a lot you wouldn't expect to hold it forever and there's a fair chance you'll have issues getting the next job if you haven't done something more common.
Eh, with COBOL I can just see them not existing at a reasonable price point and not having any avenues to gain the experience from senior people.
Say that you have a pair of chickens that people really want chicks from. Pay whatever you want. You cannot really speed up chick production because of that initial bottleneck.
Yes but also no. How can they find senior COBOL developers if there are no Junior COBOL jobs? Sure someone might pick it up for the money but they will not have “X years of experience” required to work on incredibly sensitive money systems.
Money is not the primary motivation for doing something. This is big myth. In all surveys where I come from, money comes quite a bit down on the list on what employees look for in a job. Additionally, there are factors that might be surprising, like trends (what is considered "cool", or "correct" or "noble" etc).
In the 1980s I worked for a Cobol programmer (Tom wrote accounting software for Wang VS systems, I wrote the user manuals). (Just writing that sentence makes me feel old.) I recall that one of our clients was migrating from an even older system that used wire plug cards. Literally no one knew how they worked; if one wire came out of a card, good luck getting it back in the right place. At least Cobol is more comprehensible than that.
Apparently a company in Texas was still using the IBM 402 in 2012, which works just as you describe. Swappable trays of wired patch panels for programming:
As someone who often cannot repair my own breadboard projects if they come unplugged I understand this all too well. It might have been unfixable as soon as it was out of the builder’s short term memory.
This is an interesting product of the power that automation gives a single person (or few people). If it takes a thousand bank tellers to process a hundred thousand transaction daily, then hundreds of them can leave and things will be fine. Whoever oversees the program can ask people questions when they forget the program details (because the program runs smoothly). If it takes a single programmer's work to do the same thing, you aren't going to put two people on it, but that person will someday leave. I wonder if that alone makes things more brittle.
> It changed who could write it, too. COBOL democratized coding; companies could take everyday people and train them to be useful COBOL programmers in a few months, and to become experts in a year or two. This was crucial given that companies desperately needed more warm bodies to write software.
> “You could pick people up out of the street,” says Jon Pyke, a British coder who learned COBOL back in the 1960s, “and basically and teach them how to do it.”
Well then. This does seem to suggest a solution...
Honestly, this article kind of makes me want to learn COBOL. In my fantasy, the employers desperation somehow makes it a low-stress job, like they know they don't have time for BS, they have to prioritize the most important things and just let you do your job. And they'd be so grateful.
If COBOL were that effective, you'd see derivatives of it in modern day usage. The COBOL misunderstanding is that the hard part of computer programming is the grammar we use.
I was auditing a bank’s data center once and found a working VAX that some guy had managed to keep off the inventory (along with a hundred other servers - he had his own little fiefdom going). The data center techs didn’t know what it was or who was responsible for it so they had just left it alone for as long as anyone could remember.
Are there compelling reasons that these systems can't be broken into parts and then each part gets gradually replaced in turn?
Clearly some aspects will be tied together, so for them it's all or nothing.
It does feel like these companies have got to bite the bullet and get started, otherwise that facade of being conservative will fall, to reveal recklessness.
Most of these organizations can't tell the difference between competence and incompetence, so any money they spend on IT is likely to be wasted. The more ambitious the project, the more pointless it is.
Maybe it's different in other countries but certainly in Australia, banking is a heavily regulated industry, so replacing a banking host (or even parts of a banking host) would require lots regulator approvals and sign-offs (regulator has to sign off all of the technology and the code that will be run - for existing systems, all changes still require approval, but the initial hurdle of approving something new was dealt with a long long time ago).
I suspect it's less of a technical issue and more of a people issue. Nobody wants to take the responsibility if it fails because of some undocumented/unforeseen behavior that only happens in production
Most of those cobol programs are doing something equivalent to a single SQL query.
And Cobol programs are _verbose_. Have a look at the examples on Rosetta code. C# (which isn't particularly concise) can do in 40 lines what Cobol needs 250+
Where we (modern programmers) would write a program with a large number of modules and imports, most Cobol programmers probably wouldn't. There is a lot of copying-and-pasting going on there.
That's an average program length of 3000 lines. Imagine your code base consisted of 112,500 files, each of about 500 lines (including HTML, CSS, SQL statements and "real" program code).
That's about what it is equivalent to.
Plugging that equivalent number into a Cocomo calculator, it says "20 years of 800+ programmers".
A large bank like that has dozens of lines of business, and each line of business has several processes that are automated. Then there's reporting, auditing, billing, statement generation, archival, etc.
As a bank, you also do all this stuff internally to pay your employees, contractors, create audit trails, document things, keep track of office equipment and supplies, etc.
All the things that other companies might use commercial software for, or just use Google sheets or email or another generic solution, this company has a long-established COBOL program for.
Are all 112,500 programs used? Probably not. But are 10% of them used at least once a year? Probably.
I was a contractor at cap1 (of credit card fame) 1990s. Learned some good and not so good stuff about how CC corps think about their clients. Anyway on tech/biz side:
- most cc stuff run on cobol code
- cobol code has three buckets: cash advance, purchases, other. Hard to change
- cap1 tried to rewrite that system in c++ for distributed unix to ditch cobol and mainframes. They wanted N buckets so they could hook up with N vendors and have N incentives to build biz
- big failure ala chaos report also from 1990s. Also org dysfunction. The mainframe guys fought it much like in today's world when you have old guard fight for onprem or colo DC when somebody wants a cloud provider
- cobol won then (and I haven't been back in CC since) but not for tech reasons. In truth in abs terms cobol isn't hurt or help. There's bigger adjacent fish to consider first
Exactly: as someone who sells banking backends (in C#/.NET Core with React apps and web frontends), 'old' banks are the main clients. Note though it is not only tech that they want to rejuvenate; they make it a separate part with different people that don't have the adhere to the ancient processes (outside ISO and PCI that is) that slipped into the day to day running on the bank and is costing them money and clients. But as you say, it is also responding more rapidly to demands technically.
What is intrinsically wrong with running systems on COBOL? These systems have a very long lifetime, and COBOL has worked for that entire time.
Would it really be an improvement to rewrite a banks's backend processing software in the latest fad flavor of language and framework? We know those would become obsolete in a year.
I wonder what hardware are these running on. Are they just emulating the original architecture? Surely maintaining a mainframe from half a century ago would be at least as arcane a skillset as writing Cobol.
But I agree. If some big corporation is running a Cobol training program with a big paycheck at the other end, I'll sign up. But I'm not going to spend my free time training myself, I'd rather do fun stuff.
I assume it's an issue for anyone that started using computers in banking in the 1960s or 1970s (not sure when that happened around the world but it seems to be the case for Australia, USA etc).
The company I work for writes one (COBOL —> Java, and separately COBOL—> C++ — as well as other translators for MF tooling). It took us a …while… to reach high success rates on new customer source.
There are several issues at play:
1. The language is ridiculously verbose and inconsistent. It was designed in the era when people thought the only barrier to everyone learning programming was that it wasn’t “English” enough — so stdlib functions randomly introduce keywords for “readability”, and throw consistency out the window.
2. The mainframe tries to provide anything and everything you’ll ever need, rather than relying on user-supplied libraries, and does so by adding that functionality to the language itself (combined with above arbitrary inconsistencies). Wikipedia notes 300 keywords, and probably many more terminals in general (another reference: SQL standard apparently specifies some 1700 terminals)
3. The language is itself not well-defined, or well standardized (a standard exists, but like SQL, everyone extends it arbitrarily. And again, they extend the language, rather than supplying libraries utilizing the existing languages). There are many cobol dialects in the wild. A few major players (ibm, gcos, microfocus, and a lot of little & dead ones).
4. COBOL compiler implementors (notably IBM) have/had a habit of asking customers what they needed, and adding the feature to the compiler, intending it for the one customer. Eventually other people find it too. Undocumented unspecified statements used at random.
5. COBOL does not live on its own. It expects to run under the terms of the mainframe transaction processing and batch processing runtimes. These have to be replicated as well. Additionally database (eg DB2, Oracle), filesystem (eg VSAM), third party apps, etc. Additionally, different mainframe providers have different semantics, sometimes subtle, sometimes not.
6. COBOL does things differently than Java. I consider it a fork in the timeline of language design. Functions don’t necessarily have to return to the caller. Definition order in source code matters (eg PERFORM THRU). Weird artifacts from its punchcard history (notably 70-char limit, but also weird functions like REDEFINE). It loves fucking around with bit fields. Variables are basically global, always. Structured Control flow is really a shallow layer on top of GOTO.
7. Companies with mainframes have typically already tried & failed to get off the mainframe. By translation, or reimplementation, or emulation. They’re often cautious to try again (a problem for our sales team). Lots of companies offer to do it manually, and fail on any decent sized codebase, causing companies to be quite cautious
8. Mainframes are fast at what they do, and very reliable. It’s very much a don’t fix what ain’t broke situation. It’s also difficult to meet same performance expectations when you’re emulating the whole thing — though half the point in converting is that it’s much easier to simply throw more hardware at the problem. Conversion generally is “COBOL in Java” because safely rearchitecting it automatically to something more idiomatic is often quite difficult, or not even possible without violating unspoken assumptions; its also difficult for current maintainers to verify correctness, if you’ve mucked about with the logic flow significantly.
It's all entirely outdated and should be replaced by cryptocurrency.
Cryptocurrency is not a get-rich scheme, despite everyone trying to make it into that. It's just applying math and computer science to make technically sound and trustworthy modern money.
[+] [-] jawns|4 years ago|reply
Generally, if it's crucial for the business, the lever you pull is increasing compensation until the market responds. That's how you influence willingness. People are willing to do much dirtier jobs given enough money.
"But we need someone who is not only willing but able," they say, meaning they want someone with many years of experience with the language.
These same companies did not invest the time or money to train future maintainers in the language or make it worth their while to accumulate that experience. Guess what happens when you don't invest that money up front? You pay for it dearly later on.
So it's either an impossible situation of their own making, or those elusive COBOL programmers are out there, but companies significantly underestimate how much they really need to shell out for such a specialized skill set.
Either way, I don't think the problem can be reduced to younger programmers wanting to write code in the hip newer languages.
[+] [-] Guest42|4 years ago|reply
[+] [-] nerdponx|4 years ago|reply
Socialize the losses/costs (publicly-funded school), privatize the gains/profits.
That said, there's a different side to the issue, which is that smaller companies do not (and never did) have the resources to train people. There definitely is a shortage of senior management-capable technical people who can lead projects and teams at smaller organizations. This however isn't relevant to big banks and Cobol.
[+] [-] KronisLV|4 years ago|reply
But that's the thing - these companies don't expect to be the ones to invest in these developers over the years, to let them upskill themselves. Neither do other companies. If you look at /r/CSCareerQuestions, you'll find that many of the younger devs are having quite a lot of trouble finding work, very few companies wanting to invest in the start of their careers, since they might as well just look for the more experienced devs out there.
But why is that? Simply because there is no actual guaranteed return on such an investment. A company might as well spend months of their experienced developers' time while making them mentor the more junior devs and invest a lot of resources in this, as well as have more overhead to their development because of needing to spend longer on QA and fixing bugs introduced by these juniors, for them to just turn around and leave when they've gotten the seniority that they desire.
In essence, all of this investment will return this company absolutely nothing and instead will benefit the next company that this developer goes to, which might as well be their direct competitor. Why should companies take this risk, instead of letting other companies do so, train the juniors for them and simply pluck skilled devs from the market when they become available?
I don't condone that approach, but it feels to me like a zero sum game, especially in a competitive market.
I don't have any solutions to offer, since in my eyes preparing devs should be the work of universities AND some other institution after getting their education, that would bring them up to speed to actual industry practices (like bootcamps, but for people with basic knowledge of academia).
Yet, even after getting my Master's, in lieu of such an organization, i simply had to get the practical skills over many evenings and weekends, as well as worked as a developer thanks to one of the companies that did take a risk on me, all while i was also studying. Having to work in the evenings and weekends seems a bit silly when compared with other industries, but with how much churn there is in regards to tech, i don't see alternatives.
[+] [-] robbedpeter|4 years ago|reply
[+] [-] ransom1538|4 years ago|reply
Sort of. I dealt with a large smalltalk system with it's own datastore. Finding smalltalk devs was painful. Training new ones? It was a mess. The dev environments didn't seem to port correctly to modern linux systems - mac? forget it, we could never work out contracts with Cincom Systems to get proper licenses - they would demand us pay a portion of revenue with audit rights (wtf), staging environments were layers of hacks, smalltalk could work on port 80 but making it work with apache/nginx/load balancers was always a mess, smalltalk itself was covered in bugs and would crash for no apparent reason. All new devs knew learning smalltalk was a waste of their future job prospects - they also had no good mentors. Good luck finding things on stackoverflow. The smalltalk contractors that could help would just raise their price so high it turned into extortion (one of them even wanted a portion of gross revenue). These contractors would delete histories, use hand written journals, hide documentation, refused to train anyone, not use version control, quit in the middle of meetings -- and they all were friends - it was a total shakedown. "Just pay them more" never really worked out for us.
[+] [-] surfsvammel|4 years ago|reply
I know one bank who does an academy thing, where they bring in graduates, train them for up to two years (with salary) for them to be able to work on the systems. So, it’s a problem, but they have knows to get around it.
Also. This problem is not isolated to banks. I saw the same kinds of problems when I was in telecom.
[+] [-] lordnacho|4 years ago|reply
Even if a COBOL job paid a lot you wouldn't expect to hold it forever and there's a fair chance you'll have issues getting the next job if you haven't done something more common.
[+] [-] MattGaiser|4 years ago|reply
Say that you have a pair of chickens that people really want chicks from. Pay whatever you want. You cannot really speed up chick production because of that initial bottleneck.
[+] [-] q-rews|4 years ago|reply
[+] [-] _blu|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] Finnucane|4 years ago|reply
[+] [-] tdeck|4 years ago|reply
https://www.pcworld.com/article/249951/if-it-aint-broke-dont...
[+] [-] porknubbins|4 years ago|reply
[+] [-] 6gvONxR4sf7o|4 years ago|reply
[+] [-] civilized|4 years ago|reply
Yes. Yes it does.
EDIT: again, of all the things you could downvote... I just don't get why it would be this post
[+] [-] jrochkind1|4 years ago|reply
> “You could pick people up out of the street,” says Jon Pyke, a British coder who learned COBOL back in the 1960s, “and basically and teach them how to do it.”
Well then. This does seem to suggest a solution...
Honestly, this article kind of makes me want to learn COBOL. In my fantasy, the employers desperation somehow makes it a low-stress job, like they know they don't have time for BS, they have to prioritize the most important things and just let you do your job. And they'd be so grateful.
[+] [-] hackcasual|4 years ago|reply
[+] [-] civilized|4 years ago|reply
Or they'd be a bunch of entitled a-holes and constantly try to manipulate you to extract as much value as possible. As finance execs do.
[+] [-] perl4ever|4 years ago|reply
Yeah, some already figured out, if you do that, you don't need people from high wage countries.
[+] [-] rainpain|4 years ago|reply
OG microservices.
[+] [-] zxcvbn4038|4 years ago|reply
[+] [-] nmstoker|4 years ago|reply
Clearly some aspects will be tied together, so for them it's all or nothing.
It does feel like these companies have got to bite the bullet and get started, otherwise that facade of being conservative will fall, to reveal recklessness.
[+] [-] wmf|4 years ago|reply
[+] [-] jamesfinlayson|4 years ago|reply
[+] [-] trinovantes|4 years ago|reply
[+] [-] jrochkind1|4 years ago|reply
> The Bank of New York Mellon in 2012 found it had 112,500 individual COBOL programs, constituting almost 350 million lines;
Could that really be true? Can anyone provide some context to make that make sense?
[+] [-] solresol|4 years ago|reply
And Cobol programs are _verbose_. Have a look at the examples on Rosetta code. C# (which isn't particularly concise) can do in 40 lines what Cobol needs 250+
Where we (modern programmers) would write a program with a large number of modules and imports, most Cobol programmers probably wouldn't. There is a lot of copying-and-pasting going on there.
That's an average program length of 3000 lines. Imagine your code base consisted of 112,500 files, each of about 500 lines (including HTML, CSS, SQL statements and "real" program code).
That's about what it is equivalent to.
Plugging that equivalent number into a Cocomo calculator, it says "20 years of 800+ programmers".
[+] [-] avidiax|4 years ago|reply
As a bank, you also do all this stuff internally to pay your employees, contractors, create audit trails, document things, keep track of office equipment and supplies, etc.
All the things that other companies might use commercial software for, or just use Google sheets or email or another generic solution, this company has a long-established COBOL program for.
Are all 112,500 programs used? Probably not. But are 10% of them used at least once a year? Probably.
[+] [-] dmitrygr|4 years ago|reply
Too much? Then I guess you do not need it enough...yet
[+] [-] scrubs|4 years ago|reply
- most cc stuff run on cobol code
- cobol code has three buckets: cash advance, purchases, other. Hard to change
- cap1 tried to rewrite that system in c++ for distributed unix to ditch cobol and mainframes. They wanted N buckets so they could hook up with N vendors and have N incentives to build biz
- big failure ala chaos report also from 1990s. Also org dysfunction. The mainframe guys fought it much like in today's world when you have old guard fight for onprem or colo DC when somebody wants a cloud provider
- cobol won then (and I haven't been back in CC since) but not for tech reasons. In truth in abs terms cobol isn't hurt or help. There's bigger adjacent fish to consider first
[+] [-] Nursie|4 years ago|reply
Start anew without the legacy of COBOL, using tech and skills more appropriate to the present era.
Are they repeating the pattern? Maybe, but for now they get to live in the present.
[+] [-] tluyben2|4 years ago|reply
[+] [-] IncRnd|4 years ago|reply
Would it really be an improvement to rewrite a banks's backend processing software in the latest fad flavor of language and framework? We know those would become obsolete in a year.
[+] [-] porknubbins|4 years ago|reply
[+] [-] Borrible|4 years ago|reply
https://www.datacenterknowledge.com/design/no-cobol-not-dead...
I learned it around 1999 at university. Even back then they already told that myth.
But Old Code gets younger every year:
https://news.ycombinator.com/item?id=23453972
[+] [-] rad_gruchalski|4 years ago|reply
If there was an incentive, I’d do it.
[+] [-] nerdponx|4 years ago|reply
But I agree. If some big corporation is running a Cobol training program with a big paycheck at the other end, I'll sign up. But I'm not going to spend my free time training myself, I'd rather do fun stuff.
[+] [-] ravivyas|4 years ago|reply
Hard to fathom that the banking system in emerging markets would be running on Cobol or using it.
[+] [-] jamesfinlayson|4 years ago|reply
[+] [-] aj7|4 years ago|reply
[+] [-] setr|4 years ago|reply
There are several issues at play:
1. The language is ridiculously verbose and inconsistent. It was designed in the era when people thought the only barrier to everyone learning programming was that it wasn’t “English” enough — so stdlib functions randomly introduce keywords for “readability”, and throw consistency out the window.
2. The mainframe tries to provide anything and everything you’ll ever need, rather than relying on user-supplied libraries, and does so by adding that functionality to the language itself (combined with above arbitrary inconsistencies). Wikipedia notes 300 keywords, and probably many more terminals in general (another reference: SQL standard apparently specifies some 1700 terminals)
3. The language is itself not well-defined, or well standardized (a standard exists, but like SQL, everyone extends it arbitrarily. And again, they extend the language, rather than supplying libraries utilizing the existing languages). There are many cobol dialects in the wild. A few major players (ibm, gcos, microfocus, and a lot of little & dead ones).
4. COBOL compiler implementors (notably IBM) have/had a habit of asking customers what they needed, and adding the feature to the compiler, intending it for the one customer. Eventually other people find it too. Undocumented unspecified statements used at random.
5. COBOL does not live on its own. It expects to run under the terms of the mainframe transaction processing and batch processing runtimes. These have to be replicated as well. Additionally database (eg DB2, Oracle), filesystem (eg VSAM), third party apps, etc. Additionally, different mainframe providers have different semantics, sometimes subtle, sometimes not.
6. COBOL does things differently than Java. I consider it a fork in the timeline of language design. Functions don’t necessarily have to return to the caller. Definition order in source code matters (eg PERFORM THRU). Weird artifacts from its punchcard history (notably 70-char limit, but also weird functions like REDEFINE). It loves fucking around with bit fields. Variables are basically global, always. Structured Control flow is really a shallow layer on top of GOTO.
7. Companies with mainframes have typically already tried & failed to get off the mainframe. By translation, or reimplementation, or emulation. They’re often cautious to try again (a problem for our sales team). Lots of companies offer to do it manually, and fail on any decent sized codebase, causing companies to be quite cautious
8. Mainframes are fast at what they do, and very reliable. It’s very much a don’t fix what ain’t broke situation. It’s also difficult to meet same performance expectations when you’re emulating the whole thing — though half the point in converting is that it’s much easier to simply throw more hardware at the problem. Conversion generally is “COBOL in Java” because safely rearchitecting it automatically to something more idiomatic is often quite difficult, or not even possible without violating unspoken assumptions; its also difficult for current maintainers to verify correctness, if you’ve mucked about with the logic flow significantly.
[+] [-] wmf|4 years ago|reply
[+] [-] tomc1985|4 years ago|reply
Are we talking about medical billing or software engineering here???
[+] [-] ilaksh|4 years ago|reply
Cryptocurrency is not a get-rich scheme, despite everyone trying to make it into that. It's just applying math and computer science to make technically sound and trustworthy modern money.