The "Beta Culture" in the article may be derived from or justified by the release early and often mindset of open source software. This makes sense for open source and web 2.0 products which are easily updated. The product testing is crowd sourced and reduces development costs. Economically this still works for less flexible products. Apple can release an almost finished product(iphone) and count on it's users to find the bugs and happily download updates without losing too much mind share. A television manufacturer can't release a patch, but the cost of replacing broken televisions must be less than the cost of thorough product testing.
This is annoying to consumers but as long as we put up with it little will change. Consumers 30 years ago were less tech savvy, and consequently less tolerant of having to troubleshoot a new tv. Today we deal with computer crashes all the time so we aren't as offend by a tv that crashes. We have developed a tolerance for faulty technology.
The guy just complaining, but has nothing to propose. As a hard-core C/C++ programmer I'm sure he knows nothing about development process. He's just an end-user who wants to receive all-perfect device/software with version 1.0 for no money, no delivery delay and which never fails. Naive dreamer. It takes years if not decades for every piece of technoloty to get polished and turned into product, but no consumer nor marketers can wait. Another thing is, you cannot make product perfect just by lab-testing it, you have to put it into user's hands to find out all lurking issues. You cannot guess all possible features user might want see in your product without receiving feedbacks. It's all about cycles, AKA evolution.
I generally agree with the article, though I find it a little disingenuous coming from Gizmodo. I mean, these are the guys that are feeding the fire and lambasting companies for holding products back to fix buggy software/hardware. It's partially because of blogs like Gizmodo that there is such a rush to market.
This is not really about perfection - which, after all, is impossible - as it's about creating high quality products, no matter how simple or complex they might be.
If the wheel was invented with today's manufacturing mindset, it wouldn't actually roll in first couple of years ("available in the 2.0 release!") and probably set half the cave on fire when actually doing so ("You did read the EULA, didn't you?").
Sure, there are examples of spectacular product failures. But the software industry seems to be particularly bad in this regard. We all use software that is buggy, and most of us just shrug our shoulders and say "oh, well" or post on our blogs about it. And, of course, we can tolerate these sorts of things because if my phone drops a signal or an app freezes, it's unlikely it will be as catastrophic as a zeppelin bursting into flames.
Product management would tell you that they have no choice but to rush these things to market. And maybe that's true. Also consider that some "important" software came from academic/research settings, where the pressure to bring things to market was much lower (though there is considerable pressure to publish in some cases). As an example: my employer, who writes software for a highly regulated industry, recently hired a new product manager. We have been preparing a minor update release for a core product, and he has been tasked to manage this update. He comes from a company that offered non-critical web applications. When our QC department gave him estimates for testing, he became visibly pale, and pulled me aside to ask how, exactly, they needed that much time to test. I responded that he would understand the first time he is pulled into an audit by one of our clients and is asked to explain the validation process for the software. Quality just isn't the first thing management thinks about--it's all about getting something to market.
It's seems like there is a lot more complexity in modern products but there is also not the same kind of engineering attitude to products. Working in the Internet industry I've met so many people without formal backgrounds, something unthinkable in more traditional industries.
I think that the primary problem is managing complexity and that requires more rigor and more considered product cycles. Less about feature packing and more about reliability.
I am currently using CentOS on my laptop. I've never experienced weird bugs, and everything works as expected. Isn't that boring. ;-)
CentOS is usually well supported, there is lots of tested software for it. I couldn't find an Emacs 22 rpm, but I compiled the editor myself and it took me 5 minutes.
I've tried newer distros, but I don't miss any features from them. I feel I use beta software when I try the newer ones.
the problem is that now-a-days products are so complex, you can no longer afford to wait for the product to be perfect before you release.
The guy gives an example of an old TV...but thats the thing, it was an extremely simple technology by today's standards. Now even the simplest products, requires you to mesh together dozens of different technologies to work together.
And since the web, is pretty much full of nothing but startups, they just can't afford to spend the time w/o launching asap. If they wait for their product to be perfect, someone else will release a similar product and leave them out to dry.
This is annoying to consumers but as long as we put up with it little will change. Consumers 30 years ago were less tech savvy, and consequently less tolerant of having to troubleshoot a new tv. Today we deal with computer crashes all the time so we aren't as offend by a tv that crashes. We have developed a tolerance for faulty technology.