Greg Linden

Apple advocates it but don't do it themselves. They follow the genius design method.

http://www.businessweek.com/magazine/content/05_12/b3925608.htm

This article doesn't cite it but hint's at it.

Which is obvious for a couple of reasons. Apple is paranoid that anything regarding what they work on get's out.
and Apple use the Genius design method. Apple do new things not me to products.

Other than that you must take my word for it and those I know at Apple. But again if you can find anything that proves that Apple do usability testing then by all means please share.

With regards to Amazon. I know that what matters at amazon is A/B testing.

http://glinden.blogspot.com/2007/06/ab-testing-at-amazon-and-microsoft.html

And looking at their checkout process it doesn't look like anything that have been anywhere near a usability test.

But you are missing the point here.

The companies didn't become successful because of usability testing that is the crux of the matter and the claim behind the 5USD that is wrong. To the extent it testing your product matters you can ask ANYONE. If it is that bad then why spend 5USD on a beer.

But most likely it wont be totally unusable and then the actual evidence of usability test having any positive influence on your likely success.

Quick view: http://docs.google.com/viewer?url=http%3A%2F%2Fsergey.melnix.com%2Fpub%2Fmelnik_VLDB10.pdf

Abstract:

Dremel is a scalable, interactive ad-hoc query system for analysis of read-only nested data. By combining multi-level execution trees and columnar data layout, it is capable of running aggregation queries over trillion-row tables in seconds. The system scales to thousands of CPUs and petabytes of data, and has thousands of users at Google. In this paper, we describe the architecture and implementation of Dremel, and explain how it complements MapReduce-based computing. We present a novel columnar storage representation for nested records and discuss experiments on few-thousand node instances of the system.

Overview by Greg Linden:
http://glinden.blogspot.com/2010/12/papers-on-specialized-databases-at.html

My company barely existed in the 90s - it was some research project at Stanford.

And feature sets like "processes transactions" absolutely do go away because technology (and its applications) moves forwards. This was a large part of the success of MySQL: relational databases started getting used in applications where transactional integrity really wasn't that important, and they were better off working around it (or just showing inconsistent data to the user) rather than paying the price for transactions.

Or look at this recent discussion surrounding Google Megastore:

http://glinden.blogspot.com/2011/02/comparing-google-megastore.html

Megastore suffers a large latency penalty for ACID semantics. In many applications, it's better not to take that latency hit and instead settle for eventual consistency instead.

I have no experience with Ruby template engines, including Crustache and Mustache, but of course it matters about serving clients 40x times faster. 800ms to serve me what could be had in 20ms? Amazon, Google [1][2], and others have talked extensively on speed-to-conversion ratios.

In Python land, there have huge improvements in template engines [3]. And they are not done; Jinja(2) author, Armin Ronacher, is working on a Google Summer of Code (GSoC) project [4] to speed up Django and Jinja2 templates.

[1] http://googleresearch.blogspot.com/2009/06/speed-matters.html

[2] http://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20.html

[3] http://stackoverflow.com/questions/1324238/what-is-the-fastest-template-system-for-python/1326219#1326219

[4] https://www.djangoproject.com/weblog/2011/apr/25/gsoc/

I'm not sure of what it's supposed to prove, who knows how many clients and how much money Steam lost because of slow loading/painting times or just plain broken JS. From experience I can tell that I gave up buying a game on Steam at least once because of broken jQuery.

There are real metrics from top industry leaders[1][2] to prove that loading time has a clear impact on conversion rates.

>Consider this when you need 5000 npm modules and a team of 10 to compile your startup's login form.

Unminified JavaScripts files and bloated JS are both wrong, once again: not sure of what's the point of comparing both.

[1] https://medium.com/@vikigreen/impact-of-slow-page-load-time-on-website-performance-40d5c9ce568a
[2] http://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20.html

Google found a 0.5 second delay caused a 20% decrease in repeat traffic, that persisted after the delay went away (http://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20.html)

Amazon found every 100ms slower the site loaded, they lost 1% in revenue: http://www.gduchamp.com/media/StanfordDataMining.2006-11-28.pdf

Walmart.com found a very large change in conversion rate based on page load times: ( http://www.slideshare.net/devonauerswald/walmart-pagespeedslide slide 37)

My own customers have seen 4x different conversion rate, when grouped by page load time. (i.e. same slide as walmart page 37 above, where the peak is 4x higher than the lowest performing group).

Your business probably won't fail because it's slow, but it will certainly make less money because it's slow.