Rainboe, if you look closely, I think it is not the software developers or system designers but those who think they could do it better ("how hard could it be") who are suggesting the system should be changed.
As you say, anyone who has done system or software design for a fault tolerant system knows just how hard it can be to diagnose faults reliably. It's easy enough to say that a couple lines of code would have fixed this specific situation. But it is much harder to spot all the situations that wouldn't be fixed and would be created by the change.
As a software engineer in telecoms, where I deal with all manner of fault situations (but never with people's lives directly on the line), I appreciate how much effort must go into both identifying and dealing with all manner of fault scenarios for the automation being built into airliners.
I also very much respect the feelings of the posters on here that believe the slice of cheese that should have prevented this accident came with the pilot's names on it.
However, as a professional engineer, I'm horrified that such a simple fault (that RA#1 provided invalid data without a failure flag) caused the automation (AP and AT in combination, but mainly AT) to actively fly the plane at the ground. Not once, but a second time too (by pulling the throttles back again after the first crew response to the stick-shaker). If I were an engineer responsible for this area at Boeing, I'm pretty sure I'd feel some level of responsibility - just like any of the 3 pilots would, had they survived.
I'm absolutely not qualified to come up with an engineering solution - but I suspect it would be more oriented toward identifying that there was a potential problem, and announcing that to the crew, rather than adding more hardware & software to try to cope.