I don't buy the "bugs caught early are cheaper to fix" paradigm. Most bugs are caught early without special precautions, but special precautions can be quite expensive. Most software doesn't have truly catastrophic failure cases.
If there's a bug slipping through, someone will run into it, report it, and it'll get fixed. If nobody runs into it, the bug doesn't cost anything.
This is the most economic way to go about it, which is the reason why pretty much all successful software is kind of buggy. We all like to complain about it, but then we don't want to wait an extra year for the next version either.
At the other end of the spectrum, if you need really reliable software, the solution is not to eliminate all the bugs, that's impossible. Even with perfect software, hardware can fail, bits can flip the wrong way. The solution is to make sure that errors can't bring down the airplane.
I don't think so. When one is fixing bugs locally before the thing goes into production one can use each and every debugging strategy under the sun to find the bug. If it runs 10 times slower because of generating massive logs that is acceptable when debugging locally. In production one is constrained to debugging techniques that do not disturb production. This constraint quite often makes debugging times longer by factors of 10 if not 100 while at the same time a customer is getting somewhat impatient.
Also, the bug that would be discoverable locally but not in production is a bit of a strange animal. It does happen for cases where the developer has a better idea than the user what should be happening so the user will not even notice the bug. That sounds more like features that have been specified in too much detail than true bugs, though. More commonly everything that can go wrong locally will go wrong in production sooner or later. And in production you will, on top of that, hit all of the bugs that occur once every month and that only occur if the order of inputs is a bit strange while the database is under some load. If you have not done all possible debug/test work locally the application will hit production when there still is a lot of debug work to do and there will probably be so many problems that they even start interacting with one another and produce some really 'interesting' failures.
This is just pushing testing to the customer. Why would the customer report a bug instead of switching to a less buggy product?
Why do you think the customers are going to report bugs? I can't say that I've ever attempted to report a bug on an iPhone app, Windows, etc. It's like yelling at the wind.
> Why would the customer report a bug instead of switching to a less buggy product?
All products are buggy to varying degrees. As a user, you can't easily tell if another product is "less buggy". Would you risk investing time into figuring out another program that may turn out just as buggy? No. You most likely move on with your life.
Once users are invested into your product, it takes a lot to make them switch. Every single piece of software that I use regularly is either extremely simple or somewhat buggy. I haven't switched once because of it. It's a nuisance, but not a dealbreaker.
That's not to say that I like this situation, of course I would prefer software that doesn't have bugs and glitches, but I also prefer software that exists today, not tomorrow.
The market has spoken: worse is better.
> Why do you think the customers are going to report bugs?
If it's an important bug, somebody will most likely report it. If it's not an important bug, not having it reported is most likely not important either.
> I can't say that I've ever attempted to report a bug on an iPhone app, Windows, etc. It's like yelling at the wind.
So, did you switch to Android or Linux/MacOS then? Is the grass really greener on the other side?
The cynicism in this comment really bums me out. You think it's ok to give customers a buggy product, and expect them to report the bugs, because they don't really have a choice and every other product is buggy too. You say you don't like the situation, but you're doing nothing to challenge it either.
Is your motto "When life gives you lemons, make a market for lemons?"
Fair enough, it's arguably cynical to tell the children that Santa Claus isn't real. However, we're all adults here.
The highest-quality software can not win in the software market. This is evident from the software that is out there owning the market.
Quality is a trade-off, if you spend too many resources on it, you can not compete. Catching those last few bugs takes exponentially more effort.
Moreover, there are snake oil salesmen at every corner, telling you that if only you adopted some methodology, your defect rate would plummet. It's easy to get lost in that, not actually delivering a product.
If there's a bug slipping through, someone will run into it, report it, and it'll get fixed. If nobody runs into it, the bug doesn't cost anything.
This is the most economic way to go about it, which is the reason why pretty much all successful software is kind of buggy. We all like to complain about it, but then we don't want to wait an extra year for the next version either.
At the other end of the spectrum, if you need really reliable software, the solution is not to eliminate all the bugs, that's impossible. Even with perfect software, hardware can fail, bits can flip the wrong way. The solution is to make sure that errors can't bring down the airplane.