Ah, the dilemma of the software release... When to rush out a release when the previous release you rushed out had even more new problems?... Software companies that go down this path invariably find that they have to slow down this "rush it out" mentality and go back to basics, which is better development methodology and more thorough alpha and beta testing. At this point, the unwitting beta testers (basically US!) are doing a better job than their internal alpha testers, since these new bugs are discovered pretty quickly by us... But it shouldn't be this way. Software developers should be held to the fire and be held to a higher standard before being allowed to release it, none of this toss it over the wall and let the testers find it.
In my previous life in the carrier telecoms equipment space, I saw this clear shift from reliable fail-safe software to the 'just reboot it' mentality. Early telecoms equipment never had reset buttons, because they were designed to be powered on and keep on running without ever being reset or rebooted. As more off-the-self computing equipment made their way into these equipment, reset buttons started to appear and engineers thought nothing about just resetting the unit. Of course, Microsoft needs to accept a lot of the blame for this, as that was always their answer to something not working correctly. In the case of software for cars, that same mentality should apply. Software should never lock up and require a reboot. And because of that, the testing requirements should be more stringent and thorough. Yes, it does lengthen the release times, but I would argue that is better than having to fight fires all the time with hot fix releases.
