SW has an input problem and a testability problem. On one hand, the inputs to the SW are not limited (iMessage happily accepts any image file) and testing is limited to some known inputs. Software vulnerability assesment (worst case analysis) is usually performed outside of the development process at very high costs and limited outcome.

It's probably true of lots of aspects of product design - if it's not driven from the top, it's mediocre.

The quality of SW has nothing to do with the pay. Notice that FAANG SW developers do not deliver safety critical SW.

There are more things to SW development than writing code.

You can compare this situation with Boeing. And issues they had with software of 737max.

Except for beckhoff to tc3 they haven't made it to object orientation yet, so the field is stuck as a whole in the blue screen mines of yore. Managing complexity with thin standard docs, no version control while the machines grow ever more complex sensor and actuator wise..

You can not treat modern machines like small embedded hobby devices - but the industry does.

Some outside-programmers make good money coming in and solving these yesterday's problems with proper software architecture and good c development practices. But the industries doesn't learn from this. Making software will forever not be a profession for them.

The clearest example of the difference of reliability is looking at public digital signage (on transit and elsewhere). If it's based on LED segments or something similarly basic (with old-school embedded software development) it will basically always work. New LCD Screens inside trains/busses and outside working with a modern software setup (using an OS, often with a pc architecture, quite often just displaying a website) are broken ~10%-20% of the time. Looking at (for example) busses, a large portion of the time the screen will either be blank, not display anything, old information or just wrong information. Going inside fast food restaurants with large LCDs for the menu, often something is broken, frozen or something else.

It is of course possible to make modern software more reliable. It's just much, much harder than making embedded software or PLC programming reliable. Software can be easily made more complex, but it's hard to make it non-complex or to wrap the complexity so it isn't an issue anymore. The ecosystem isn't set up for non-complexity.

If we went back to Dijkstra's notion of correctness by construction, then a specification for the program would be made, and then a programmer would prove their part of the code correct to the specification. They would write the precondition and postcondition of every effectful statement, document the invariant of every loop, and prove by induction that each loop does what it's supposed to do. Basically, annotate your program with Hiare triples. (There are books about how to do this). Then, extensive tests should be run for as much of rhe program as possible.

Nowadays, we have tools for this so that we don't actually have to write a proof by induction for every loop; instead, we have bounded model checkers. In theory, the manual proof writing could be isolated to the parts of the program whose properties a bounded model checker cannot verify.

However, it seems like this whole plan is infeasible unless regulations are written that enforce this onto the industry. It would make them a lot less productive, and therefore less profitable. The only benefit would be that software is more reliable. By necessity, it would have to become simpler, too. For instance, there's absolutely no way that web browsers like Chromium, with 38 million lines of code, will ever be verified, because they're too large and complex.

I'm not sure if you remember older software properly. The idea that an entire desktop computer, much less a web browser, could even run for weeks without a reboot would blow the mind of '90s me.

Netscape Navigator was the direct cause of at least 80% of the Mac OS 8/9 crashes I've experienced in my life. It was less common for the browser to entirely take down a Windows system in that era but I sure do remember seeing a lot of those application crash dialogs until the modern era of tabbed browsing made people care more about stability.

Prior to Windows 7 becoming mainstream I never had to check uptime when diagnosing weird behavior on end user computers because they just naturally got rebooted regularly. Now there are a lot of computers that only reboot when they receive updates that require one, and depending on the user might not get those updates very often. I see systems that haven't been rebooted in the better part of a year and some times longer every few weeks. Even more now with Windows 10+ "Fast Start" where "Shut Down" actually means hibernate so users who think they're shutting down every night actually haven't had a fresh boot in months.

Not always a blessing and I've actually recently been thinking (e.g. in context of Lua) if object orientation is in most situations not better to avoid.

The issue is as machines get way more complex this issue gets worse. Also there are generations of PLC devs that still want to stick with ladder logic. Huge fragmentation.

The fact is the unmodernized plc platforms deliver working machines and plants. The projects are built, commissioned, and unlike modern software they are finished and left to operate instead of constantly modified With no benefit to the end user

Don't get me wrong. <PLC programmers> tend to also have electrical skills and some are pretty good at their jobs, and you can learn a lot from them!

But ... they're not programmer programmers. It's a different skill-set with only so much overlap.

controlling physical processes like oil refineries, power generation, or sawmills is different from most computer programs as are the consequences of bugs or errors so it makes sense that it takes different people with different interests and skills.

PLCs replace relay circuits for Industrial Electrical technicians (hence: Ladder). And make no mistake: relay circuits are important, and is something they are very adept at!

However, this doesn't imply that they are automatically able to write or debug regular Python or C code or what have you.

-----

PS. If you let a PLC programmer at any language, they'll find a way to do ladder logic. Illustrative example (combining some features I've seen in textbooks and IRL, formatting included):

  if Tank_Level_Reached == True and EF132121 == False and Ready_To_Start == True and Finished == False and Belt == Not_Ready and Stage == 5 and Position_Left_Arm == Up :
    move_left = True
    move_right = False

   if Tank_Level_Reached == True and EF132121 == False and Ready_To_Start == True and Finished == False and Belt == Not_Ready and Stage == 5 and Position_Left_Arm == Down:
   move_left = False
   move_right = True

   if Tank_Level_Reached == True and EF132121 == False and Ready_To_Start == False and Finished == False and Belt == Not_Ready and Stage == 5 and (Position_Left_Arm == Down or Position_Left_Arm == Up):
    move_left = False
    move_right = False

There are more "engineers" writing software for your car or a train than "engineers" at Microsoft, Google, Apple or Facebook.

I don't think that someone will be happy when driving with 100 km/h on a highway, the car will suddenly decide to restart itself. There are bugs everywhere where profits are put before engineering but calling those people names is not constructive. Especially when they use SW created by "engineers" which crash with no apparent reason when they are doing their work.

Of course I'm half joking, but I wouldn't be surprised if software problems contributed to the delays (which tend to chain, as trains need to wait for each other, etc).

It took more than 1h to start going back, and I wonder how much of it was making sure the track is clear, and how much was "rebooting the train" or whatever else was necessary.

Haha wait until you find out how TVs worked in the 70s and how fast it was to change the channel *sob*

My take is this: the peak is at the point when a given product category existed long enough to be thoroughly developed, but short enough that value engineering didn't kick in yet to ruin it.

(To be fair though, nowadays we have UHD/4K channels, which need way more bandwidth than the SD TV quality from 2000s. I wonder if this could be fixed with a more powerful CPU in those boxes? maybe it could, but might increase power usage?).

Audio effects and synthesizers all have software driven versions that sound effectively identical to analog and are typically cheaper. Yet, analog has been hanging on due to the simplicity and immediacy.

It is way harder for different computerized systems to work together due to the higher complexity and more obfuscation (a traditional logic circuitboard is often easily reverse engineered. Reverse engineering software is a very specialized task). This is also very noticeable in other sectors, where interoperability has become much worse due to moving to proprietary digital protocols.

This is in part due to the difficulty in getting software approved as compared to previous tech (due to software being so intransparent) but also because of truly lacking quality. One of the reasons Bombardier was so deep in trouble was bad software, even leading to a contract of over 40 ordered trains just being cancelled ([2]).

In my opinion building reliable (and understandable) software is way harder than building logic or even mechanical systems. I don't know what the solution is, but it's been a problem for a long time.

[0]: https://www.vrt.be/vrtnws/de/2013/02/12/belgische_bahn_storn... [1]: https://www.augsburger-allgemeine.de/augsburg/Neue-Zuege-auf... [2]: https://de.wikipedia.org/wiki/Bombardier_Talent_3#%C3%96BB

Everyone in this thread seems to be forgetting that those might be useful and not just fancy toys. I prefer trains that have digital signage indicating their location, and connections at the next station. Higher level of automation in trains (e.g. Communications-based train control) also drastically increases efficiencies in speed and scheduling, allowing more trains on the same tracks, and minimises time wasted waiting or accelerating/decelerating needlessly.

The problem is poorly implemented software, not the existence of software.

You know? Shortly after German reunification they appeared in NRW in front of, or behind (pushing them/'Wendetraktion') the Regional-Expresses, S-Bahn, doing the heavy lifting of mass-transportation there, on all or at least most important relations in the Rhine-Ruhr-Area. Not that much later we got DOSTOS there, but brand-new ones.

I remember wondering why that was at the times, and that they couldn't be bad at all, because otherwise they'd break down more often, leading to delays. Which I rarely experienced at the times, as almost daily user.

Die verdammte Scheissbahn war da noch in Ordnung!