4 ms·

The title seems to apply to Apple, too (see iOS and Yosemite WiFi bugs), and could probably be applied to Google, too (Hangouts bugs, Lollipop problems, etc). B

by jaxbot 12y ago

The title seems to apply to Apple, too (see iOS and Yosemite WiFi bugs), and could probably be applied to Google, too (Hangouts bugs, Lollipop problems, etc). But mistakes happen and many bugs are less obvious to reproduce than others, so I wouldn't point fingers too hard, personally.

TheOtherHobbes 12y ago
If a car blew up and left you stranded whenever you filled it with gas, or unlocked its doors whenever you left it out in the rain, you'd demand a refund and perhaps compensation. 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.
- breischl 12y ago
  Seriously! You never hear about a car would accidentally accelerate when you try to brake, or that the tires would spontaneously blow out, or that they would just plain roll over. I mean, the phrase "automobile recall" is practically an oxymoron! [1] - https://en.wikipedia.org/wiki/Toyota_Prius_(XW30)#Recall https://en.wikipedia.org/wiki/Toyota_Prius_(XW30)#Recall [2] - http://www.forbes.com/2000/08/18/mu3.html http://www.forbes.com/2000/08/18/mu3.html [3] - http://www.cbsnews.com/news/toyota-will-recall-lexus-suv-for-rollover-issue/ http://www.cbsnews.com/news/toyota-will-recall-lexus-suv-for...
  - dangrossman 12y ago
    The fact that "automobile recall" is something that exists and is expected when defects occur, but "software recall" largely does not exist, was his point.
    - wvenable 12y ago
      It's almost as if software and automobiles were completely different things! These comparisons are pointless. 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.
    - LLWM 12y ago
      Automobile recalls are necessary because it's impractical for automobile manufacturers to remotely deliver and install a fix to your car. Software can and does work that way, which is much more convenient for everyone.
    - breischl 12y ago
      His point, as I read it, was that the software industry does not operate to the same quality standards as the auto industry. Which may have some validity, but is not as obvious or clear cut as he was implying. "Software recall" does exist, they just call it "applying updates" instead.
    - mark-r 12y ago
      I worked for a company that did a voluntary software recall once. That was back in the days when it meant shipping out CDs.
- Retra 12y ago
  Well, if my car did that, I would just back up, reformat, and reinstall. So I don't see why the auto industry puts that much effort into preventing problems that are so easy to fix. It's not like you're in danger or anything -- just use some cheap redundancy.
georgemcbay 12y ago
This was my reaction as well. 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 12y ago
  [deleted]
  - georgemcbay 12y ago
    That's a good point, but (admittedly based entirely on my own anecdotal experience) I'd argue that much software is now bad in ways that are far less subtle. 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.
mikestew 12y ago
Having worked on and off in software testing for the last fifteen years or so, I'm becoming increasingly convinced that there's a correlation between the recent trend of calling software test teams "Quality Assurance" and general purpose software that seems to get less stable as time goes on. Bear with me on my admittedly whacky theory that I haven't completely fleshed out yet. 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.

by jaxbot 12y ago

TheOtherHobbes 12y ago

If a car blew up and left you stranded whenever you filled it with gas, or unlocked its doors whenever you left it out in the rain, you'd demand a refund and perhaps compensation. 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.

breischl 12y ago
Seriously! You never hear about a car would accidentally accelerate when you try to brake, or that the tires would spontaneously blow out, or that they would just plain roll over. I mean, the phrase "automobile recall" is practically an oxymoron! [1] - https://en.wikipedia.org/wiki/Toyota_Prius_(XW30)#Recall https://en.wikipedia.org/wiki/Toyota_Prius_(XW30)#Recall [2] - http://www.forbes.com/2000/08/18/mu3.html http://www.forbes.com/2000/08/18/mu3.html [3] - http://www.cbsnews.com/news/toyota-will-recall-lexus-suv-for-rollover-issue/ http://www.cbsnews.com/news/toyota-will-recall-lexus-suv-for...
- dangrossman 12y ago
  The fact that "automobile recall" is something that exists and is expected when defects occur, but "software recall" largely does not exist, was his point.
  - wvenable 12y ago
    It's almost as if software and automobiles were completely different things! These comparisons are pointless. 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.
  - LLWM 12y ago
    Automobile recalls are necessary because it's impractical for automobile manufacturers to remotely deliver and install a fix to your car. Software can and does work that way, which is much more convenient for everyone.
  - breischl 12y ago
    His point, as I read it, was that the software industry does not operate to the same quality standards as the auto industry. Which may have some validity, but is not as obvious or clear cut as he was implying. "Software recall" does exist, they just call it "applying updates" instead.
  - mark-r 12y ago
    I worked for a company that did a voluntary software recall once. That was back in the days when it meant shipping out CDs.
Retra 12y ago
Well, if my car did that, I would just back up, reformat, and reinstall. So I don't see why the auto industry puts that much effort into preventing problems that are so easy to fix. It's not like you're in danger or anything -- just use some cheap redundancy.

georgemcbay 12y ago

This was my reaction as well. 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 12y ago
[deleted]
- georgemcbay 12y ago
  That's a good point, but (admittedly based entirely on my own anecdotal experience) I'd argue that much software is now bad in ways that are far less subtle. 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.

mikestew 12y ago

Having worked on and off in software testing for the last fifteen years or so, I'm becoming increasingly convinced that there's a correlation between the recent trend of calling software test teams "Quality Assurance" and general purpose software that seems to get less stable as time goes on. Bear with me on my admittedly whacky theory that I haven't completely fleshed out yet. 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.