edit: I have hopefully fixed all of the places where I incorrectly parsed "worked on software for" as indicating employment. > They have a real potential to en

edit: I have hopefully fixed all of the places where I incorrectly parsed "worked on software for" as indicating employment. > They have a real potential to end peoples lives in the event of failure I hope the lessons[1] learned from the Therac-25 are part of the design. Anything that dangerous needs to have defense in depth. If there are hardware limiters, interlocks, etc adding redundancy to the software check, the risk should be no worse than repairing any other dangerous machinery. Alternatively, if John Deere is relying on the software alone for safety checks - which requires that they (and the OEMs!) write bug-free software - then I don't want to be anywhere near the affected products. > these tractors do (in testing) fail in spectacular ways. So it's software only. I'm amazed at the hubris of thinking it's even possible can guarantee a software project large enough to requires a couple hundred engineers that maintain "the largest, most complex codebase [you] have ever interacted with". The very existence of tests failing in "spectacular ways" is evidence that bugs do exist in the software. > These are not riding lawnmowers. I'm not aware of anybody that suggested they were. > They are 30-ton combines, and 20 ton tractors tilling fields Yes, just like the older combines and tractors that didn't require complicated software. > Joe Farmer isn't going to have a fucking clue how to repair their software correctly. This, really, is the key point: the farmers in question *are not trying to repair the software. The only reason it is involved at all is because John Deere the company) chose to add the dependency. [1] http://sunnyday.mit.edu/papers/therac.pdf http://sunnyday.mit.edu/papers/therac.pdf