OnQ Blog

Good Enough?

May 13, 2010

Qualcomm products mentioned within this post are offered by Qualcomm Technologies, Inc. and/or its subsidiaries.

“Close enough for government work!” This is the battle cry of the bureaucrat; a phrase uttered in jest (and seriously)… countless times a day… in sprawling cube farms bathed in the comforting glow of fluorescent light. It’s an allusion to the belief that government standards are lower than in the private sector and that job security is higher, so why go the extra mile?

A similar question could be put forward in the world of smartphone software engineering. Why go the extra mile to deliver higher quality software? If you’re anything like me, your PC suffers blue screens, it hangs, etc. and you probably grudgingly accept it, reboot and move on with your day, right? How about your smartphone? I can honestly say that my phone is far more reliable than my laptop. In fact, I almost wonder if it’s too reliable. Don’t get me wrong, I love the fact that it can run seemingly forever without a reboot, but I wonder at what cost?

Here’s my point: most people use a relatively small set of features on their phones, but they use those features constantly and heavily. These are the features/applications that must be bulletproof. These features/applications should also be the first things that are developed and integrated into the platform, so that they may benefit from the maximum number of verification cycles before the product ships.

I believe it’s fairly easy to determine the applications, use cases and features that are in most demand by the consumer. Some are painfully obvious (e.g., homescreen, phonebook, messaging, calendar), while others may take a little more market analysis to determine.

Unfortunately, it seems that I spend far more time listening to discussions of obscure user cases dreamed up by engineers, not end users that do indeed stress the system, albeit in ways the vast majority of the population will neither experience or care about. I’m not saying that pathological use cases should be ignored altogether. However, I don’t feel that they should be allocated the same amount of resources for verification as the critical, most commonly used features should.

This approach would address two critical issues in the smartphone industry: development cost and time to market, both of which are vitally important to the manufacturer and consumer. What do you think? Do we as an industry spend too much time perfecting things nobody cares about? Do we have the right balance? Or should we be spending even more time on these features/apps/use cases?