4 ms·

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 atti

• SteveNuts 3y ago
  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.
• monocasa 3y ago
  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.
• ebiester 3y ago
  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 3y ago
    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 3y ago
      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!)
      • giantg2 3y ago
        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.
      • Spooky23 3y ago
        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.
  • dustingetz 3y ago
    ha! you wouldn’t even be permitted to bid the project!
  • quickthrower2 3y ago
    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.
• bastawhiz 3y ago
  > 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 3y ago
    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 3y ago
      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.
      • deleted 3y ago
        [deleted]
      • bumby 3y ago
        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 3y ago
          Yet the DoD's bureaucracy is neither combat nor inspection ready.
          • deleted 3y ago
            [deleted]
• wmf 3y ago
  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 3y ago
    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 3y ago
      > 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 3y ago
        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.
• wredue 3y ago
  >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.
• giantg2 3y ago
  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.
• psunavy03 3y ago
  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.
• Spooky23 3y ago
  If my experience with an unemployment system is a guide, the COBOL is fine. The scaffolding around it, different story.
• jrockway 3y ago
  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.