Are you an unemployed software engineer?

[brucehoult]

I am!

And I even got paid to write a COBOL system for Whangarei City Council during my university holidays in 1982/83.
.. snip ,,

I'm happy to report that I made sure the code was Y2K-proof :-)
I've sometimes wondered whether that stuff is still in use.

I am no longer surprised at the common life experience I have with some forum members. My first paid programming job was fleet vehicle maintenance records and statistics system built from the ground up in COBOL during summer holidays 1979. The summer job was instigated by a mechanical engineer who wanted to light a fire under the computer services department which was stalling him. So I landed into this political mess,  I was all on my own and had to fight the people who controlled access to the Univac 1108 mainframe and who wanted to see me fail, but I didn't.

Yeah, something similar in this case too. The bureau who owned the computer (a PR1ME by that stage, not the B1800 I'd used as a highschool student in 1980) were dragging their heels over implementing this system. I'm not sure if they were actively opposed to the council getting a student to write this system, but I think they weren't thrilled.

My code was for sure not Y2K proof, two digit year codes everywhere for the win!. Also I never wonder about it as the company went under some 20 years later

Sadly, that bureau insisted I use two digit years to save storage space. I had quite a fight with them about it. In the end I used two digit years but I had a special database table with one record which contained several parameters including a "century rollover year". I initially set this field to "50" meaning that 50..99 meant 1900+year while 00..49 meant 2000+year. I provided a UI for adjusting this parameter, after checking that any loans with dates falling between the old and new base values had already been aged (deleted) from the system.

If they're still using that code and still raising loans with maximum 30 year term then 2020 will be first time they've *had* to adjust the parameter.

[SiliconWizard]

Why switch to languages that have a long track record of software security issues and nasty bugs?

Productivity, integration, cost, staff availability, better tooling, better user interface.

The two first are nice buzzwords, but the effective benefits using more "modern" languages don't always hold in real projects.

What do you mean by "better user interface"?

Regarding staff - and cost, which is tightly related for software development - things are not necessarily as obvious as it may seem. Of course you can find way more developers for Java, Python or the like. Numbers don't make quality or success though. A couple of very experienced developers (which you are more likely to find among COBOL developers) can be a lot more productive than 10 Java kiddies. So this shortage may actually be a plus rather than a minus.

There certainly are very few people able to develop in COBOL these days, but as long as there are enough to get the job done, I don't see the problem. Sure they are highly paid given the shortage (which motivates them even more to do quality work), but does that make projects more expensive in the end? I'm not convinced, and experience in other fields has often taught me otherwise. And given the current situation (you may wish it were different, it won't change reality), I think anyone serious about working as a software developer in the banking/financial domain should still learn COBOL. It's fine not to be interested in these domains whatsoever though.

Then of course comes the main point: maintaining and evolving legacy systems. Rewriting software from scratch has a long track record of spectacularly failed projects, in all kinds of domains.

Lastly, as I said, COBOL seems to have evolved quite a bit, and I believe it even has object-oriented features these days.

You can write bugs in COBOL too.

Of course. My point here was, using domain-specific languages, there's a whole range of bugs/security issues that you can avoid compared to using very general-purpose ones.

FORTRAN was also another interesting example.
Of course you can write numerical analysis software in C, C++, Java, Pascal, Ada, whatever. (And I have - I'm not specifically advocating FORTRAN, I have never used it outside of uni.) But there's a good chance it'll take the average specialist more time, introduce more bugs, and will make them have to look for third-party libraries that may be costly or utterly buggy, or take months writing their own. So that's really about domain-specific languages and tools.

[coppice]

Why switch to languages that have a long track record of software security issues and nasty bugs?

Computer languages split into ones with a long track record of software security issues and nasty bugs, and ones with a short track record of existing.

[bd139]

Why switch to languages that have a long track record of software security issues and nasty bugs?

Productivity, integration, cost, staff availability, better tooling, better user interface.

The two first are nice buzzwords, but the effective benefits using more "modern" languages don't always hold in real projects.

They're really not buzzwords.

Productivity is the ratio of time spent to problems solved. You want to have a library of tools which is adaptable to all problem domains without having to reinvent any wheels if possible. Integration is the ability to interact with disparate other systems. No system is an island now.

I'd like you to show me how much work is involved in a realistic case of financial portfolio valuation without modern languages. The task is basically:

1. Map a list of product providers to portfolio items (around 60,000,000 daily) and retrieve them from a mix of SQL boxes and document stores.
2. Fracture this out into distinct queues per provider.
3. Fire this at about 40 different distinct integrations (ranging from shitty bits of SFTP, SOAP, XML, HTTP, JSON, custom protocols all using different auth methods ranging from OAuth to broken ass custom X509 certificate CAs) using batching.
4. Reliably poll, or be sent responses.
5. Match the responses to portfolios (this actually is a very complex matching engine which is nearly 2 MLOC on its own to give you an idea of the scale).
6. Update database and document stores
7. Dynamically generate 60,000,000 portfolio reports in multiple document formats
8. Print them and stuff them in envelopes and order deliveries across 25 countries...

I'd love to see how someone even approaches that with anything that is older than a few years. We're just onboarding protobufs channels. Do you have an implementation of protobufs for COBOL?

What do you mean by "better user interface"?

Someone who knows windows or a web interface can sit down and use it without having to use some shitty terminal emulator or turd written in some vile GUI toolkit dragged along (mostly whining about HP / ME10 / CoCreate shite there but it exists elsewhere).

Regarding staff - and cost, which is tightly related for software development - things are not necessarily as obvious as it may seem. Of course you can find way more developers for Java, Python or the like. Numbers don't make quality or success though. A couple of very experienced developers (which you are more likely to find among COBOL developers) can be a lot more productive than 10 Java kiddies. So this shortage may actually be a plus rather than a minus.

LOL that's just complete bollocks. Sorry

In COBOL you pay someone to write the libraries then they write the application.

In Java you pay someone to write the application using the libraries off the shelf. You also get a test suite for your money. You get documentation. You get continuous integration and delivery. And importantly you get to choose the target architecture not be constrained by it.

There certainly are very few people able to develop in COBOL these days, but as long as there are enough to get the job done, I don't see the problem. Sure they are highly paid given the shortage (which motivates them even more to do quality work), but does that make projects more expensive in the end? I'm not convinced, and experience in other fields has often taught me otherwise. And given the current situation (you may wish it were different, it won't change reality), I think anyone serious about working as a software developer in the banking/financial domain should still learn COBOL. It's fine not to be interested in these domains whatsoever though.

There's no problem at all. The key problem is the celebration of this as a way of life. The world moved on and the only reason anyone is fanfaring this shit is to hide the legacy problems the business has.

Absolutely no one should be learning COBOL in 2020 entering the banking and financial sector.

Then of course comes the main point: maintaining and evolving legacy systems. Rewriting software from scratch has a long track record of spectacularly failed projects, in all kinds of domains.

That's a fair point. Only idiots rewrite systems from scratch and do a grand switch over. Migration to new tech should be a carefully controlled and phased "evolution". The platform I'm working on now is slowly eating away at legacy and moving over to a much more distributed model behind the existing interfaces. Eventually they will be replaced as well. But at no point is anyone pulling the plug and rewriting from scratch.

Lastly, as I said, COBOL seems to have evolved quite a bit, and I believe it even has object-oriented features these days.

It's really quite fugly though. Also most of our stuff isn't actually OO even though it's written in OO languages.

You can write bugs in COBOL too.

Of course. My point here was, using domain-specific languages, there's a whole range of bugs/security issues that you can avoid compared to using very general-purpose ones.

Yes we build domain specific languages to express complex problems as well. The matching engine above uses a DSL to define rule chains and a formal verification framework to validate them and the system behaviour afterwards (as it compiles them into parallel streaming implementation).

Shit's complicated!

FORTRAN was also another interesting example.
Of course you can write numerical analysis software in C, C++, Java, Pascal, Ada, whatever. (And I have - I'm not specifically advocating FORTRAN, I have never used it outside of uni.) But there's a good chance it'll take the average specialist more time, introduce more bugs, and will make them have to look for third-party libraries that may be costly or utterly buggy, or take months writing their own. So that's really about domain-specific languages and tools.

Most of our stuff is in C#. Including the numerical analysis stuff. Most of the modeling starts in Mathematica or Excel though or is which is how it goes these days.

[donotdespisethesnake]

I recently had a job upgrading a custom system with an obsolete language, it was quite obscure even at the time. There was literally only one guy in the company who knew how to build and use the run time debugger. The management thought it would be a quick upgrade, and had no budget for anything like improving the tools. I said right from the start it was going to take a lot longer than they thought, and sure enough the project went massively over schedule and over budget. The customer was so pissed off, they threatened to cancel but were too committed. They wrote an assessment report recommending that they never place an order with our company again.

The whole set up was really nothing like I had encountered before, but the really weird part is that the dysfunction was considered completely normal, and the only thing required was long working hours (unpaid overtime of course!). The management refusal to spend any time or money on improved tools, training, IT support etc guaranteed failure, but they were completely unable to see it. As far as they were concerned they had a "working product" which only needed minor changes.  I had to quit for the sake of my health and sanity, I feel a little guilty about that because the rest of the guys would have to work even harder.

So it doesn't surprise me that technical debt can build up to a point where it is impossible to repay, and disaster is inevitable.

[Syntax Error]

PROCEDURE DIVISION.
COBOL... take it out into the barn and shoot it.

Seriously, COBOL is the reason why IT departments have a wierdo employee who's been working in the same corner of the office since 1982. His cheese plant died in 1990, but he's still got the pot. And he's looking after some mysterous legacy database that's even older than the CTO. But only he understands the Db2 database syntax and, how to boot up that antique IBM workstation with the black and green VDU. And what that VDU is connected to, no-one knows. You can hear him tapping the SysReq key late at night, as he waits for the line printer to get spooled. The line printer died in a dumpster in 1998, along with his marriage.

[chickenHeadKnob]

PROCEDURE DIVISION.
COBOL... take it out into the barn and shoot it.

Seriously, COBOL is the reason why IT departments have a wierdo employee who's been working in the same corner of the office since 1982. His cheese plant died in 1990, but he's still got the pot. And he's looking after some mysterous legacy database that's even older than the CTO. But only he understands the Db2 database syntax and, how to boot up that antique IBM workstation with the black and green VDU. And what that VDU is connected to, no-one knows. You can hear him tapping the SysReq key late at night, as he waits for the line printer to get spooled. The line printer died in a dumpster in 1998, along with his marriage.

Man that is harsh, dude. Have some brotherly love for your fellow code-bro's.
I may slightly resemble some aspects of the depiction above. 

[bd139]

Just creep over there, drop a python book and run away 

[TK]

Yes, show some respect... maybe he is maintaining your company's payroll system that pays your salary every month...

[Syntax Error]

Harsh, you ain't heard nothin' yet

Yes, show some respect... maybe he is maintaining your company's payroll system that pays your salary every month...

They would have upgraded payroll in 1991 to a bleeding edge RDBMs like Adabas/Natural. And then done nothing until the arival of a distruptive Javascript bootcamp graduate in 2014, whose system pays wages as random number strings via Paypal.

COBOL guy has seen them all come and all go.

[bd139]

Yes, show some respect... maybe he is maintaining your company's payroll system that pays your salary every month...

That's funny. My first proper IT job was replacing a System/360 and all the staff that ran the company's payroll. We joked that the entire dev cost was less than the electricity bill for the S/360 for a year 

The system that replaced it was 16 bit VB and did the payroll run on a mid-range Pentium box faster than the S360 did and delivered it via EDI to the bank.

It has probably been replaced again since then I will add. I'm wondering how you'd get a mainframe running COBOL to integrate with OpenBanking or something 

[Syntax Error]

@bd139 I remember back in the day when EDI was the big new B2B voodoo (like blockchain is today). On our floor we had an EDI expert team. A bunch of intense ex-military types who thought lunch hour was for marathon training. My tech support team where just too busy fixing the leaking database to eat lunch.

Connecting COBOL to the cloud? I guess there's some amazon.elastic.crap.cobol.api for that? Back in the mainframe day, this was achieved with tape spools to magnetic cartridges using flaky JCL. Then mailing the cartridges to a data processing center somewhere in north London.

Thinks, is anyone still using MySQL outside of a Raspberry Pi?

[bd139]

Hahaha those guys still exist. Actually I just bagged a couple of Ciscos which were used as EDI diallers until very recently. 

I know a guy with a large business running on MySQL. It’s still there. I wouldn’t go near anything other than Postgres and redis myself these days.

[boz]

I wouldn't have any issues running production systems on MySQL, Postgres or even SQL Server.. It's not 2005 anymore, get over it.

[bd139]

SQL Server, SQLite and Postgres fine.

MySQL nope. It has done a thousand things to kill its reputation over the years. When there’s an option on the table I wouldn’t poke it with a stick. It doesn’t even deserve attention.