I've previously wondered at why so many consumer apps and devices have slow end-user performance, even though their programmers knew the hardware platform they were targeting when they wrote the software. The laggy Comcast DVRs and Apple iPhone 3G are notorious, iTunes is painfully slow on MacBooks, and we all know Eclipse lags badly on anything short of a supercomputer. I'm sure you've encountered some app where you press a key and wait... and wait... and wait... before it responds.
When I previously asked what's behind people shipping such slow software, Bob Murphy and Mike Dunlavey suggested that it's a social and management problem:
This isn't a technical problem, it's a marketing and management problem.... Utimately, the product mangers are responsible to write the specs for what the user is supposed to get. Lots of things can go wrong: The product manager fails to put button response in the spec ... The QA folks do a mediocre job of testing against the spec ... if the product management and QA staff are all asleep at the wheel, we programmers can't make up for that.
People work on good-size apps. As they work, performance problems creep in, just like bugs. The difference is - bugs are "bad" - they cry out "find me, and fix me". Performance problems just sit there and get worse. Programmers often think "Well, my code wouldn't have a performance problem. Rather, management needs to buy me a newer/bigger/faster machine." The fact is, if developers periodically just hunt for performance problems (which is actually very easy) they could simply clean them out.
So, if this is a social problem, what social mechanisms can an organization put into place to avoid shipping slow software to its customers?
Do you make perf testing a first class QA priority and have them submit bug reports on each lag? But it shouldn't take a letter from QA for a programmer to realize that a 3 second lag between keypress and response is unacceptable — should all programmers do their own QA so they see such issues immediately?
Is this an automated testing problem? Some apps have built-in watchdog timers that detect when the UI thread stalls for more than a second, but then what should the timer do? Catch a callstack and send it to the bug DB? Set off a USB airhorn at the tester's desk?
Should we keep seltzer bottles on hand, ready to douse people who parrot cliches about optimization and the root of evil? Hang a banner in the lobby that says "writing a UI stall is like spitting in the customer's face?" Forward every angry customer email about slow performance to the whole team?
If what ultimately matters in performance is that the customer never wait more than 0.1 second between input and response, what social and procedural mechanisms can an org put in place on to day one to make sure the product ships that way on day 500?