I've got a huge issue with all the stories about the "software" being supposedly at fault. The problem was never about the software per se; it was about the avionic specs on system level.
You can do very complex things without even involving software - including non linear things - or by involving it but not necessarily in a primary characterizing way. What happened here was in no way a software failure except if you generalize the meaning of "software" to include the whole lifecycle of the domain it's applied to, and the comprehensive corresponding engineering. And that's what tons of "purely" software people (by that I mean people working in a field where the non-software components are only ancillary to making the software run, in huge contrast with what happens in avionics) are doing too often in that case. Except what failed here was good old boring engineering, risk analysis, and properly conforming to regulations. The software "worked", in the sense that it did precisely what it was designed to do. But what it was designed to do was stupid. And deciding what it should do was not a "software" thing. It was an avionics one. It is not possible to conflate the tech and the domain in this area, in contrast with what you can do for e.g. some websites or some smartphone apps.
There was software involved, but it is not more interesting in this case than noting that there was electronics involved. And it could also have been done through a mainly mechanical apparatus, but the only reason it did not is that software is more convenient. But that's an implementation detail that played very little role in the tragedy (unless Boeing is waaaay more fucked up than we are even all discussing about, but I actually don't expect that).
Another example is the Swedish fighter jet Gripen. So sure, it’s doable, but not as a quick hack (“if the single angle-of-attack sensor goes above X degrees force the nose down by changing stabilizer angle”). Any engineer worth his salt should be able to tell the difference.
You can do very complex things without even involving software - including non linear things - or by involving it but not necessarily in a primary characterizing way. What happened here was in no way a software failure except if you generalize the meaning of "software" to include the whole lifecycle of the domain it's applied to, and the comprehensive corresponding engineering. And that's what tons of "purely" software people (by that I mean people working in a field where the non-software components are only ancillary to making the software run, in huge contrast with what happens in avionics) are doing too often in that case. Except what failed here was good old boring engineering, risk analysis, and properly conforming to regulations. The software "worked", in the sense that it did precisely what it was designed to do. But what it was designed to do was stupid. And deciding what it should do was not a "software" thing. It was an avionics one. It is not possible to conflate the tech and the domain in this area, in contrast with what you can do for e.g. some websites or some smartphone apps.
There was software involved, but it is not more interesting in this case than noting that there was electronics involved. And it could also have been done through a mainly mechanical apparatus, but the only reason it did not is that software is more convenient. But that's an implementation detail that played very little role in the tragedy (unless Boeing is waaaay more fucked up than we are even all discussing about, but I actually don't expect that).