Ease of updatability is also a factor in the increasing acceptance of bugs at release. If your bug can be fixed by an over-the-air update that can self-install with zero downtime to the end user, they're going to be much more forgiving than if it requires a man with a white-coat to come and swap all the ROMs in your mainframe over the period of a month (or worse, get his soldering iron out and start unwirewrapping!).
The other key factor is the industrialisation of software development - it's no longer a specialised industry with a few players working for huge companies who demand quality over price. Today price is the biggest driver of development, with "fix it once it's out there making money" a key measure for the people financing the work.
As for safety critical software being somehow above all this, all I can do is point to the holes in the ground that used to be 737 MAX's.
You have a very strange view of mainframe computers. From my experience we updated at the end of the working day and tested ready for the next morning. No soldering irons or other hardware changes.
As for a specialised industry with a few players it used to be quite the opposite. Most larger companies had their own software department and looked after their own software. There was more choice of operating systems. Despite that there were standard languages like COBOL.
I might be wrong but I think the main problem with the Boeing 737max was not exactly a software bug. It was a desire to make the plane perform like the previous versions of 737s to such an extent that the pilots knew no difference. I think the pilots were not even supposed to know there was an extra piece of artificial intelligence in the control stream. The 737max had a tendency to stall and the software was designed to put the plane into a dive to avoid this. But pilots were not to know of this feature and it led to some cases of planes diving into the ground. No one really thought through how the software should be specified.
Umm it takes as long as it takes isn't a robust way of running a project and it seems to me software has now been allowed to get so complicated its almost impossible to test it.
Need to get back to the level of simple, but very effective, electromechanical electronic control that was deployed on the Victoria Line in the mid 1960's.
I agree things are over complicated and thus rather fragile. Crossrail een when working smoothly will never cope with trains presented out of order due to delays on the older lines that are dealing with other services. Trouble is that the reason for making it so complicated is to maximse the use of the infrastructure. Infrastructure is so expensive that technology start to look attractive. Wat I maen is we really need less trains in the core and more cross london tunnels.
Minor point of order - every piece of complex software that is still being changed is riddled with bugs. Most very inconsequential enough they'll never be found, some quite the opposite...
Case in point:
https://nickgregory.me/linux/security/2022/03/12/cve-2022-25636/
It's not just Linux - even the Apple kernel you mentioned has severe bugs discovered from time to time, i.e:
https://www.cvedetails.com/cve/CVE-2006-4392/
I'm a software developer, so this is very much in my area of expertise. Complex software engineering is very, very, very hard, which is why the mantra is always make things as simple as you can, because it's primarily the interactions between components and systems that introduce spiralling complexity.
Yes. It is easy for non-software experts to underestimate the complexity which then leads to unrealistic expectations and unrealistic deadlines.
Maybe when it got old and the technology had been abandoned, i don't like to use obsolete as there is this temptation to believe everything new has to be better than what preceded it, but that simple technology delivered 10's millions journeys safely and reliably. Im not a luddite and realise there have been huge benefits but what im contending is technolgy in the second decade of the 21st century has many examples of it just getting too complicated in part I believe due to too much inter connectivity between systems. So in future we should just question if we want or need all this functionality that computers and software can provide. Reality is hardware is relatively cheap but software engineers aren't and certainly testing it all isn't.
It is true that we have become obsessed with things looking nice. Look at windows and the processing power required to produce all those different colours and shades of colours all on the screen. Now, ignoring photographs and videos, most of the software we use would be fine to use if it were just black and white.
Ironically this post just underpins an argument that I've posted on RailUK Forums more than once that the railway (and especially the UK railway) has allowed a plethora of random technical standards with indifferent interfaces to prevail, particularly since privatisation. This is where buyers flock to the cheapest bid where manufacturers offer their pet systems ignoring integration, that not insignificant element of cost of ownership, that excalates as incompatible systems and interfaces clash. The buyers have got what they paid for. Unfortunately, 'its buy cheap, struggle through with it' , - there's usually no 'buy twice' option.
Oh yes indeed. I recall replying to one of your posts "there is nothing like standards and there are no standards". As an example - how many different signalling systems are there on Crossrail and its extremities !.
