I think software has existed in computer systems for 7 or 8 decades now - and the pitfalls are well understood.

I think the problem is one of simplicity vs complexity. New systems today rely on dozens - hundreds even - of packages and libraries - many of which are not written by the implementer. How can you ensure reliability in all these components?

This is why engineering from first principles - even in today's software development environment - is important. Unfortunately, the trends are in the other direction.

It's a liability when you're getting equipment serviced, whether there's software or not. We have a Cat 287B skid-steer. After a month of inactivity, it wouldn't come out of "park" mode. A mechanic lifted the cab, tested a couple of solenoids, and stated "must be a bad computer". This is an old machine, so I called Cat and confirmed that it doesn't actually have a computer. I took up the floorboard and found some wires that had been chewed by rodents. We're lucky we don't have a computer, because replacing it wouldn't have helped...

Software is like any other technology. It can be a liability or an asset or both depending on how it’s built.

Sometimes software fails and sometimes it even kills people, but how many lives has it also saved because of things like collision avoidance and accurate navigation?

The trend over the last 20 years has been that 1: airliners are getting safer and safer and 2: airliners contain more and more software. True, the software introduces new failure modes. But the presence of software in airliners seems to be less a liability than the absence of software.

My take-away is a little different: As software grows it is hard to quantify.

If you have several small distinct systems, you can often quantify them down to inputs, outputs, and expected logic. Once systems get too complex, you have too many possible states, and bugs are harder to find (and the system cannot be fully defined).

I often go back to the famous Therac-25 accident. The bug in Therac-25 existed LONG before the accident, but there were two systems interacting, one system checked the other system's output and threw away invalid state. Once those two systems were merged, it was only then that the bug turned into an accident.

If aircraft stopped building monolithic software and instead built parts that ran on software, parts that could each be individually verified, it would likely result in safer software.

Indeed. And that is just an extension of the danger presented by electronic systems generally.

When learning to fly sailplanes, I was always grateful that the "primitive" wood, steel and canvas gliders I flew had purely mechanical linkages between the controls and the control surfaces, and only one instrument that required electricity at all (and even that was duplicated by a purely mechanical version).

Obviously automation has great advantages, but inevitably the increased complexity comes with risks which are more difficult to fully comprehend.

> I hope people are beginning to understand that the presence of software in any system is a liability.

I do not understand this point of view.

If you don't have software, you are going to replace it with something mechanical. Or with people. Or lose the functionality entirely.

Do you want to bring back a 'flight engineer' to operate airliner engines?

Do you want to bring back mechanical autopilots? Analog computers? Let's ditch GPS while we are at it (GPS failures can cause deaths, specially under poor visibility).

After serverless comes codeless.

Boeing 777 is also digital fly-by-wire and has never suffered an issue attributable to software error.

More precisely. For two systems offering the same functionality, the one that does so using less software should be preferred, because software of any nontrivial complexity is irreducibly buggy.

Correction: "I hope people are beginning to understand that the presence of poorly-tested software in any system is a liability."