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
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.
Today, the payroll supervisor has no idea how many processes work.
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.
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.
>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
It will be guaranteed to run in 100 years time.
Any other language can die or have incompatibility issues. Over that timespan.
I am not convinced Node will be here in 100 years.
* assuming that the 100 years hyperbole is accepted
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.
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.
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.
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.
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.
This is the same code that uses two-digit years and doesn't support lowercase letters?
That serves as evidence against this point, though:
> COBOL in 60s was written with a lot more focus on lasting in general.
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.
Managers need to be careful of Goodhart's law. (in this case "passing inspection" may not be the best target)
The DoD does not.
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.
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.