Hacker News Reader

Gonna take a wild guess and say old mainframes and COBOL. When I trained at St. Lawrence, they were training us on that for the Ontario government, since they had a heavy reliance on that style of technology. It was way cheaper to continue to train fresh and ignorant new students to learn the old ways than to convert to anything new and decent.

Once installed in the Ontario government, there was kind of a divide between people who wanted to move on up to the Federal government (seemingly they were not concerned about skills not being transferrable, hence my guess on COBOL and old mainframes being in use), and the other half who wanted to just put in their time in one place and collect their paycheque and pension.

Also, can confirm on the expensive contractors. IBM in there pushing Rational Rose and hardcore waterfall did nobody any favours at all.

> mainframes and COBOL

Exactly. My first job out of university in 1996 was with the Canadian government. One of my first tasks was to update a COBOL program that had originally been written in 1972. I left that job in 1997, but I doubt the program I updated has changed much in the 24 years since, so it's at least 48 years old at this point.

> I've heard stories of developers creating fancy UIs to cover up ancient Fortran software, so that it's less painful to work with, but they don't need to replace the underlying software.

An API is an API. As long as the interface is well designed, my POST request can release a carrier pigeon on the backend for all I care.

> 2) Only in 2019 did the US Nuclear Command transition away from their own 50 year old technology: floppy discs from the '70s. [1]

From my reading of the article, it appears they are still using 1970s era IBM Series/1 minicomputers. It sounds like all they've done, is replaced the physical floppy drive with a floppy emulator. This is a device which attaches to the legacy IO bus, and appears as a floppy disk drive to the minicomputer, but the actual data is stored in flash memory instead of magnetic media.

https://en.wikipedia.org/wiki/Floppy_disk_hardware_emulator

Nuclear tech is completely different from IT solutions. Same with aerospace. 'Change' implies massive risk to the system. If something works, leave it. If it doesn't need to be updated too often, then make as few changes as possible.

You need to think of things like that like a low-scale industrial system. It needs to do what it does.

If you go to a candy-store at the beach and see a 150 year old saltwater taffy machine, you say "ooh, cool". The thing that makes a missile go up is essentially the same thing, it needs perform it's function to spec, period.

Yup. In tons of industrial settings it's common to have machines that are a century or more old.

I know someone who works for an industrial gear company and routinely reconditions things like draw bridge mechanisms or a rubber rolling mill (do they call it a mill?) and most customers just want things to keep on working like they've always been working since they've built their process around them and machine throughput is rarely the bottle neck. The improvements customers go for are modern bearings (quiet and cheaply serviceable) and if they have to have gears made they generally opt for a more modern tooth profile (potentially stronger, quieter and more efficient).

>Since minor changes can affect the meaning of these agreements, they are only edited or amended in the software in which they were originally created.

How much difference can switching from word 2007 to word 2016 be? Even switching between microsoft office and libre office, the only thing that would get mangled is the formatting, not the text itself.

I can imagine (badly-drafted) agreements where things are specified by page number or level-of-indentedness, like "Until the major conditions listed below are met, the government will supply the items listed on Page Y." If those references were inserted manually, any formatting changes could have unintended consequences. If they're done automatically (with SmartText), they might break in other software.

I would guess it's mostly paranoia--you'd have a hard time convincing a judge that the one orphan item that spilled over onto page Y+1 wasn't meant to be included--but I can sorta see not wanting to risk it.

In this case that's probably the right approach. The rest of the hardware it's connected to must all be custom and probably can't handle anything other than that specific floppy interface, even at the wire level. As long as it's documented somewhere it's fine.