The Shared Suffering Hypothesis, or setting things up the way everyone else does

Tinkering endlessly with computer hardware and software can be fun… if you have the time. As for me, I eventually came to the paradoxical conclusion that the more I tuned a product to my specific needs, the less likely the product would actually work as intended—and the less likely I could find someone to help me when a problem did arise. Product manufacturers often tout the ability of their products to be configured to a user’s idiosyncratic needs, but maybe users can most effectively minimize heartache this way:

The Shared Suffering Hypothesis: You’re best off configuring a product so as to maximize the number of other people who can help identify and resolve problems with that configuration.

Here’s an example: A number of years ago I set up a media PC, eschewing the small number of commercial media PCs then available to get a tricked-out gamer PC. I maxxed every spec—video card, hard drive, etc.—and for its day, this machine rocked. What didn’t occur to me was that, with each component I picked, I was reducing the number of other people who had the same device I had. And upon receiving the box, I wiped it and installed an early beta of an obscure OS version. Fantastic! Now I had a blazingly fast PC, the likes of which were possessed by no one else on the planet!

I was a user community of one. When sorting through the inevitable driver weirdness and other nightmares, I had no one to turn to for help, because no one else shared this configuration or anything like it. The OEM and its component manufacturers, of course, had no experience with that OS, nor had the OS manufacturer ever tested on any of that hardware. The nascent media PC user community couldn’t help either. This left me solving every configuration issue on my own. I spent hours on exciting tasks like trying to see if the PC motherboard would cope better with the hard drive configured for RAID 0 or RAID 1, or maybe I should try RAID 5? Damn, and all I wanted to do was watch TV on this thing.

Lesson learned, when I bought a new media PC a couple years later, I abandoned impressive computer specs in favor of amassing the largest number of people who could share my problems. If I ran into a problem, I wanted a hundred other people to have already hit it and collectively solved it. I purchased a basic media PC from a huge OEM—not because they made great media PCs, but because they sold a lot of them. I purchased the most vanilla configuration possible, more or less blindly accepting the OEM’s self-serving default hardware recommendations. The more defaults I could accept, the more likely it was someone else would have something like the same box I did. When the box arrived, I tried hard to avoid changing anything from the default config, and in generally avoided installing funky apps on the box. In the end, the new PC wasn’t a perfect media experience—but it worked, and I spent very little time keeping it that way.

(And now the impending forced cutover to digital cable in the U.S. is going to kill me. It’s forcing me to rebuild a perfectly good media PC setup, all so that our seldom-watched analog cable TV can now be a seldom-watched digital cable TV. Once again I’ll be searching for the solution that involves the least weird configuration.)

The problem here are the economics of configuration. You’d think you’d benefit by tailing a product to your needs, but I believe in most cases that benefit is overwhelmed by the benefits of not customizing. And the issue has implications for software designers: each time you add an option to your product, you might be making things worse for your users, not better. I’ll take a cut at that question in the next post.

Next time: The economics of configuration