Wired magazine has the article Boeing Plans to Fix the 737 MAX Jet With a Software Update.
When the MCAS detects the plane climbing too steeply without enough speed—a recipe for a stall—it moves the yoke forward, using the horizontal stabilizer on the tail to bring the nose of the plane down.
I have read that airplanes have an audible stall alarm that actually says “Stall, Stall” or something like that. Over 300 people might be alive today, if the plane also gave the warning “Stall, Stall” that most planes have when the automatic system decided to override the pilot’s ascend instructions when the pilot pulled the stick back. The pilot might have thought “OMG, I am about to stall” under actual stall circumstances, or the pilot might have thought to shut off the automatic system if it was obvious that the stall warning was false. In the actual situation, the pilot did not even know that there was an automatic system making its own decision about where the stick should be.
When I was writing software and doing customer support for that very software, I had a principle I tried to follow when my software had detected an error and was going to take some action. Instead of having an error message that said something like the following:
Error: Your snagafratz is wrong.
I would try to put in as much information as the software knew about the error. It would go something like this.
Error: You entered “sniggledypoo” which is not an expected value for snagafratz. snagafratz can only be “foo” or “bar”.
If you actually entered “sniggledypoo”, but the correct values were either “foo” or “bar”, you would have a pretty good lead to solving your problem, perhaps without even referring to the user manual. If you didn’t enter “sniggledypoo”, you might start looking for reasons why the software did not receive what you thought you told it. If all else fails, you could call tech support, and read me the message. I might know exactly what has gone wrong, or I might know where in the software to look for a bug.
As tech support, I found it helpful when a customer could call me and read me the full error message. Even better was when I did not get calls because the customer could solve the problem on her own or his own.
I learned how to write better error messages because every call to tech support was an indication of something in the software that could be improved. The fewer calls that came in, and the fewer bugs that had to be fixed, the more time I could spend developing new features.