[uticus]

Of course, devil's advocate would point out COBOL in 60s was written with a lot more focus on lasting in general. They didn't largely have the same general attitude of 'we iterate quickly with our script kiddies' as is prevalent today.

Not that all software from then was wonderful. Or that COBOL magically guarantees great code.

But, on the flip side, you can't say the code base isn't battle-hardened (to various literal degrees).

* edit: corrected sp

[ebiester]

I can build you a team using today's (quality: average B2B startup) programmers and today's methodologies that will write software for 40 years.

It will just cost twice as much as the team that iterates quickly. It will cost more because I will spend more money on business analysis up front. I will spend more money writing automated tests. Most importantly, I will maintain my own toolchain and libraries or pay someone to do so. Every piece of software deployed will have someone accountable to my business to maintain it.

It turns out that this is expensive. It's no more expensive than maintaining the COBOL code, mind you, and would likely give you better results than the equivalent COBOL code. Most companies will take their chances with less expensive software because that's what their competitors do.

About a decade ago, I saw one of the major systems you talk about up close. While they spent that amount of money for mission-critical systems, they didn't do nearly as good of a job on the average software in the system. I'm not convinced that any business is ready to go back to the battle hardened days.

[docandrew]

I wonder though whether the up-front costs incurred by your team would eventually be outweighed by the long-term costs of the quick team.

[ebiester]

I am not convinced that it would. The quick team will get to learn three times as much and adapt to the actual customer need. The cost of change in a system built with stability as a quality attribute will be higher. (As you can see from a system like the old mainframes!)

[Spooky23]

The advantage that the original cobol people had is that they had functional manual processes to model.

Today, the payroll supervisor has no idea how many processes work.

[giantg2]

Mainframes are expensive because they're niche and basically a duopoly. The companies supplying them know their days are numbered and charge high prices before the market goes dry.

In my experience, the quick teams only learn the surface content. A lack of depth tends to result in more errors down the road and poor architecture. But I guess it doesn't matter since half your team will jump to the next project company in 2-3 years anyways and take that knowledge with them.

[satvikpendem]

> using today's (quality: average B2B startup) programmers and today's methodologies that will write software for 40 years.

I'm not sure I would trust these people over those of the past, regardless of what they say they will accomplish, Chesterton's Fence, and the Lindy Effect, and all.

[johnnyanmac]

I imagine that is exactly what:

>spend more money on business analysis up front.

Entails. But sure, if the government doesn't want to pay for that quality, they can spend just as much or more resurrecting Cobol devs in cryo-stasis in 2099

[jrockway]

I don't think they have to keep COBOL devs in cryostasis. Some sufficiently motivated individual could likely learn it today. There are even programmers alive right now that would see a large legacy system and not immediately suggest a rewrite on their first day. It's rare but it can happen!

[dustingetz]

ha! you wouldn’t even be permitted to bid the project!

[quickthrower2]

The trick is to use JS. (Not anything that compiles to it)

It will be guaranteed to run in 100 years time.

Any other language can die or have incompatibility issues. Over that timespan.

[kube-system]

I can't tell if I'm being Poe's Law'd. JS engines are a moving target and have been ever since it was called LiveScript.

[satvikpendem]

Just use LISP!

[ebiester]

You could use Java or Python and have the same guarantee.

I am not convinced Node will be here in 100 years.

[ak39]

Node might not, but Javascript (even on the server) will mostly be.*

* assuming that the 100 years hyperbole is accepted

[trealira]

Programming languages haven't even been around for 100 years.

There's no guarantee we'll even be running programs written in C in 2123, let alone ones written in JavaScript. 100 years from now is a long time.

[satvikpendem]

> It will be guaranteed to run in 100 years time.

This is never guaranteed. How do you know that nothing will change in JS land in 10 years, much less 100? You don't, that's how.

[klyrs]

Brainfuck is the only language we need. It's feature complete and practically guaranteed to go unchanged in the next millenium.

[monocasa]

Also throwing out there that COBOL was a language designed by the DOD specifically for managing it's bureaucracy.

It was a naval research project headed by Admiral Grace Hopper to program with words rather than formulas like earlier "high-level" "autocoders", enabling secretaries to transfer their business logic into computers. It actually intentionally has a lot of the same structure as a recipe, hoping that this would allow easier uptake by secretaries.

[wredue]

>Of course, devil's advocate would point out COBOL in 60s was written with a lot more focus on lasting in general. They didn't largely have the same general attitude of 'we iterate quickly with our script kiddies' as is prevalent today.

I worked on enterprise cobol for nearly 20 years and can generally attest that cobol code from the 60s is absolutely nothing at all what you’re describing.

It’s brittle and constantly breaks, requiring 24/7 on call support for people to deal with issues so it doesn’t hold up the next days work.

It was not written with any semblance of engineering prowess. Most cobol written in the 60s was written by business managers, not programmers.

The reason it stays running isn’t because it’s battle hardened. It’s because nobody in their right mind would ever pay to untangle the unfettered mess.

[SteveNuts]

It'd be battle hardened to 1960s standards, payroll has changed a _lot_ since then. And if they can't accurately describe exactly how certain calculations are made (or have to do some of those manually outside of the program after it runs), that would be a huge problem in an audit.

This is why big companies use Oracle or SAP for their ERP, auditors are very familiar with it and the way it functions is well-known and understood.

[wmf]

COBOL in 60s was written with a lot more focus on lasting in general

This is the same code that uses two-digit years and doesn't support lowercase letters?

[cwbriscoe]

COBOL ONLY USES 2 CHARACTER YEARS IF THAT IS THE WAY IT WAS CODED. PEOPLE DIDN'T THINK THEIR 60'S - 90'S CODE WOULD STILL BE RUNNING IN 2000. COBOL DOES SUPPORT lowercase LETTERS. GET WITH THE TIMES!

[trealira]

> PEOPLE DIDN'T THINK THEIR 60'S - 90'S CODE WOULD STILL BE RUNNING IN 2000.

That serves as evidence against this point, though:

> COBOL in 60s was written with a lot more focus on lasting in general.

[cwbriscoe]

Yeah, that point is wrong in my opinion. I don't think programmers back then tried to build things to last any more than programmers today do.

[bastawhiz]

> you can't say the code base isn't battle-hardened

Your statement is undermined by the fact that the system has failed its sixth consecutive audit. If it's not hardened against failing an audit, I'm not really sure what it could possibly be hardened against.

[bumby]

Part of Murphy's Laws of Combat: No combat ready unit ever passed inspection. No inspection ready unit ever passed combat.

Managers need to be careful of Goodhart's law. (in this case "passing inspection" may not be the best target)

[bastawhiz]

And yet hundreds of thousands of companies pass the same audits. The call for audits came from ridiculous amounts of misreporting and waste. Accounting systems that can't do accounting and deal with trillions of taxpayer dollars should not have the goalposts moved. A 0.001% error in a trillion dollar system is ten million dollars. That's taxpayer money that could fix derelict bridges or pay for thousands of children to receive lunch at school.

[bumby]

I agree with you, but I’d venture to guess most of those companies would use “combat” in that sense as an analogy.

The DoD does not.

[herewulf]

Yet the DoD's bureaucracy is neither combat nor inspection ready.

[bumby]

I tend to think the combat portion is a matter of scope. It’s hard to do everything, everywhere, all at once regardless if that’s on a politicians wishlist. The only force noted as “strong” by the Heritage Foundation readiness index is the Marine Corps and that’s a result of acknowledging they are a one-war organization of limited scope. That all goes to say the scope of the DoD is unlike any other organization on earth, so quips like “well, companies pass these inspections all the time!” is of little value.

[psunavy03]

Having worked on a team responsible for maintaining COBOL code, if from the 80s and not the 60s, it may "last," but it's also a rats nest of dependencies that's a pain in the ass to test, and part of the problem of moving away from it is 40 years of undocumented business logic baked into it over the years.

[giantg2]

Even when I started 12 years ago in Java/JSF/Oracle stack there seemed to be way more focus on durability and longevity. The system I started on was architected in a way that made it easy to modify and integrate with other system. It worked well. Eventually it's scope creeped, which would necessitate modernization. But it was very maintainable and lasted years.

Now the systems I work on are hot garbage because the tech is constantly needing upgraded versions, changes to the code are onerous because of the way the system was designed, we are constantly having data issues for various reasons, and people jump teams every 2 years so there's no continuity.

I'm convinced it's a leadership issue. Push for speed and you'll get it. It will cost you in other areas.

[jrockway]

This just sounds like survivorship bias to me. I am sure there is a lot of junk COBOL that killed the companies that relied on it. Nobody cares today because the business is gone.

Something that's interesting to think about is that because the cost of changing COBOL is so high now, only the most important change requests actually get implemented. Compare that to a team that can develop and ship a change the same day; their efficiency leads to more requests that end up being bad ideas. The Pentagon has designed a system to ensure that only the most well-thought-out ideas make it into production, they just went about it in a very strange way.

[Spooky23]

If my experience with an unemployment system is a guide, the COBOL is fine. The scaffolding around it, different story.