It's a testament to the usefulness of lawyers that the big players in the software industry don't even pretend they can work at the level of professional and managerial competence offered by almost all other consumer and B2B industries.
[1] - https://en.wikipedia.org/wiki/Toyota_Prius_(XW30)#Recall [2] - http://www.forbes.com/2000/08/18/mu3.html [3] - http://www.cbsnews.com/news/toyota-will-recall-lexus-suv-for...
Reliability of hardware or software is a trade off. If your software or hardware is responsible for keeping people alive then more time and money is spent on ensuring its stability and that is then factored into the cost.
"Software recall" does exist, they just call it "applying updates" instead.
What is called "quality assurance" is really "quality control" in the places I've observed. The difference is subtle. For example, at my last position I carried the title "Director of QA". That was a made-up title that didn't mean anything. It didn't mean anything because if I were truly a manager of QA, then when dev throws something over the wall that has no code reviews and no unit tests, I'm empowered to say, "no, we're not shipping this". But as we all know, that's not how it turns out. Instead my team is "quality control" because we're just testing the output and have no empowerment over the creation process. In other words, we're a test team, so quit with the "QA" crap just because it has the word "quality" in it. As the saying goes, you can't test in quality.
With that, I see two trends. One, which has been going on for a while what with TDD and the like, is an increase of the testing burden on dev. This is, generally speaking, a good thing IMO, especially if dev can be backed by a dedicated test team. Where it goes off the rails is what I hear from my Microsoft friends: there is no more test, "devs" (many of whom might be converted testers that may or may not be qualified "devs") are responsible for testing, too. Don't ever rely on your own testing if you're a dev. You'll test it the way it was written, and you'll not only miss edge cases but likely scenarios as well.
Could this explain the steaming pile that was the Xbox One (the only MSFT product I have in the house, or use, these days) in its early days? Could it explain the unbelievably buggy, nearly unusable, _Halo: The Master Chief Collection_ we got from a Microsoft studio? Dunno, could be coincidence, but it conveniently fits my theory; might want to grab some tin foil.
Trend #2 is a regression bug: throw shit over the wall and hope test finds the bugs. Call 'em "QA" so that when the quality isn't there we have someone to blame. That's what we used to do 20 years ago, then we as an industry got a clue and put some quality onus on dev while test got brought into the process earlier. Maybe it's just my corner of the world, but many seem to be going back to just that (I left my last position mainly because of that reason, after they bait-and-switched me between the interview and the actual work.)
Could be that tools that help with quality haven't kept pace with the increasing complexity of software systems. Could be, but I'm not sure I buy that. We've got tools I could only dream of 20 years ago (Xcode's point-and-click profiling tools, code coverage tools, static analysis). Test modeling tools need some work, but at least they exist.
I think an overly simplistic answer is that the industry doesn't know what to do with software test. We know we need some, but damn does it cost money. So how can we minimize that cost without appearing to just throw up our hands? After all, most of us are not building the guidance control for space probes, so who cares if Angry Confectionary Squashing Avians crashes once in a while? Instead we throw an understaffed and unempowered team of victims at the problem, then scream "why didn't test (pardon me: "QA") find this?!"
That's my take on it, anyway. I'm astounded at the poor quality of most software I encounter, but I think the general user population is used to thinking that it's either something they're doing wrong, or that's just the way software is. There are no late night pitchfork parties along Microsoft Way or One Infinite Loop, and people keeping paying, so there's not always a huge incentive to do otherwise. Many of us have said we'd pay for an upgrade that included nothing but bug fixes. Companies think otherwise (and they're probably right). Apple had their Snow Leopard, which they had to give away, but I can't think of any other examples.
Solutions? Oh, I've got a few but this is getting long-winded and rambling, so I'll spare those of you that stuck with me this long.
Now that I'm a dev I really wish I had some competent testers to work with. It's really impossible to test your own work, because you're inherently optimistic about your code. Testers need to have the mindset of "there's a bug in here somewhere, and I'm going to find it."
I've had a lot more serious problems with my Lollipop-updated Nexus 5 than I have with my Windows 8.1 desktop PC over the past month.
Software quality in general is IME pretty bad these days and the problems go way beyond just Microsoft.
Deleted comment
While there has never been a time where I haven't constantly been running into software bugs, these days I seem to encounter a lot more situations where the bug is so obvious that it is impossible to believe the company didn't see it during development and so egregious that I can't believe they released the software anyway.