Agreed. It ran for 30 years and hasn't had problems (other than the radio interference issue). Anything that has lasted for 30 years has had nearly every bug worked out or worked around. The only things that survive for 30 years are systems that do the job.

Until a single point of failure hits and you're in a mad-scramble to get a replacement system up and running.

Exactly! That's the ultimate problem with these kinds of systems. It's why I advocate incrementally re-engineering a compatible system onto modern hardware and standards. Not even anything fancy necessarily: just easy to maintain, portable, and fast enough. Companies like Semantic Designs even make source-to-source compilers that do bug-for-bug translations. I'm sure we could do dynamic translation of binaries for the dependencies, too, although I'm not sure anyone does that.

This. Nobody today would even consider trying to design something so simple it could last three decades. And certainly nobody would want to support it. Everyone wants shiny and new...

Whether or not they realise it, I think people are building brand new systems right now, using cutting-edge technology, which will survive until 2045.

Some arduinos with an ethernet shield and a super simple web backend?

Nah, somebody would say it need json-serialized config files, a flash-file system, a rails-based admin login running on a few amazon instances for fail over....

"Simple" Ha. There's this whole coprocessor in the ethernet shield with its own proprietary implementation of TCP/IP and who knows when someone will find a serious bug in it. Then in 30 years you have a TCP/IP stack with a serious security issue and no way to patch it!

Ethernet is great, but thirty years from now it and/or RJ-45 might sound just as antiquated.

Doubt it; 10Base-T is 26 years old, and still works with today's modern 10Gbase-T NICs.

There will be backwards compatibility options for an awfully long time.

How right you are. On the other hand I'm continually surprised that my paycheck in 2015 comes (more or less) from a descendent of an operating system I learned in the 80's.

Sure. And then it's time to retire it, after a job well done.

The software would only be a small part of this project. The issues they discussed in the clip (risk of sudden failure, radio interference) were hardware issues.

Its not the code that's concerning, its the hardware. The idea that they never bothered to virtualize or emulate this in 30 years says a lot about how IT is run at that school.

A single developer could emulate whatever IO goes to that radio and have it controlled by a simple computer with redundancy. I wonder what they're paying the original developer to maintain this turkey. I imagine he's charging enough to where the sunk cost fallacy is obvious here.

What I find interesting is all the places where FOSS is lacking. There doesn't seem to be a popular and well managed FOSS climate control system. Is anyone making standardized controllers, thermostats, etc? This stuff should be a commodity by now. I'm guessing its hard to work with all the proprietary HVAC stuff and its also an unsexy problem to solve. I'd love to replace my thermostat with a raspberry pi and have a lot of fun modern features. There's a hackaday article about someone doing this, but its a pretty primitive project.

There are some projects to start bring FOSS ideas/ideals to building system controls and decision making like this, but I think there are significant difficulties in the variety of proprietary systems and reluctance to change due to capital costs and/or maintenance contracts.

https://github.com/VOLTTRON/volttron from Pacific Northwest National Lab is one example.

> Is anyone making standardized controllers, thermostats, etc?

http://www.bacnet.org/

It is true that old code is not necessarily bad code. However, HVAC system controls have had very large improvements in efficiency over the last 30 years. HVAC systems are the single largest use of energy in a commercial building and the improvements that modern controls can offer in efficiency can greatly offset the costs of installing those new systems.

I think they got very lucky that the original programmer didn't move away or decide he didn't want to maintain this thing anymore, whenever some dingus from the school district decided to bother him. I'm seeing a lot of people ignore that aspect of the situation. There's a reason we talk about the bus number.

I'm mostly a back-end guy... does it really matter if you you use != vs !== when you know that both operands have the same type in javascript? In this case, you've got string literals, so (flying spaghetti monster, I hope there won't be any type conversions going on)

It matters for anyone who maintains your code. "!=" is a big red flag, better to consistently use "!==".

True. Hardware, though, does get old.