Does buggy software anger you?

A big trend in software in the last decade, is to put out software as soon as possible. The internet, and the world wide web in particular have made it possible for developers and software companies to push updates to their users, on a monthly, weekly or even daily basis. Before the ned, software had to be burned onto a disc, which had to be packaged and shipped to a user, making updates to software was expensive.

Because it used to be expensive to get updates to clients, software had to be as close to perfect as possible before it was shipped to the customer. In today's world, as soon as the product is usable, it is put online, for milions of people to use. This is because of the 'fail fast' mentality that exists with developers and technology companies today. Instead of hiring lots of testers, they're crowdsourcing that to their customers. That doesn't mean they just ship any product without testing, but the cost of testing can be reduced by fixing bugs as they are encountered by the users. With a user base of 100.000 users, you're already doing more efficient testing than a team of 100 trained testers could do.

Is this a good approach? For software companies, it certainly is, for the reasons mentioned before, however, as a consumer, you don't want to see screens telling you about unexpected errors, corrupted data, or lost connections. When you use a product, you want it to work perfectly. You don't want to spend 10 minutes filling out a bug report with the details of exactly what you were doing when something broke.

But I agree with Jeff Atwood's post, where he states that shipping imperfect software is better, in order to help developers discover the unknown unknowns, discover where the software that worked in the sterile lab, wil crash in the real world, as long as developers actually listen to the feedback users give them. For companies, there's a tuff choice here. How much trouble can users stand before they loose faith in your software, or even your entire company? Many people stopped using siri, because it became unreliable. And,as a company produces more and more high quality products, the tolerance of users for quirks and bugs becomes lower. This may sound strange, as you'd think that as a company brings out more quality software, it deserves a bit more credit, but this is not how users think. Users want to get what they expect. If they expect a great product from a company, because it has a history of bringing out great products, they'll be much more shocked and angered, than, if they would get another flash version that crashed their browser, that's just business as usual. (sorry, adobe, but it's the truth).

Taking feedback

There are also companies that try to deliver a good user experience within the testing. Users don't like filling out forms, especially after they've just had a bad experience with crashing software. Tracking a user's behaviors, can lead to a lot of the data found in such bug reports or feedback messages. When google tracks what links you click on in a search result page, they can find out how effective their pagerank algorithm is. If you need to scroll down, or even go to later pages in search results, to find what you're looking for, that signals that the algorithm isn't finding the best content for your query.

The problem is that this doesn't help finding the unknown unknowns, you're not tracking something if you don't know you should be tracking it, so you still need some place, where users can enter textual, freeform feedback, which can contain data you otherwise wouldn't know about. The best way, I think, to take feedback is to use both. Track what you can, to spare users from typing in the operating system and version, the browser name and version, the type of connection they're on,...