(Thanks to the most beautiful developer I know.)

The subtitle of the book is And Over 100 Other Stories of Embarrassing and Funny Stories of Technology Gone Mad. It collects a number of humorous incidents where software or software-related processes have gone awry and made the papers, causing great embarrassment for the companies responsible. I wouldn’t call them epic fails, because in the 21st century, epic fails are fleeting. These are legendary failures still half-remembered and fully documented for posterity.

Reading through the book, one identifies some areas of risk to pay particular attention to if you’re trying to prevent your company’s failures from becoming the stuff of legend and Snopes articles. These include:

• Preventing the leak of test data.
  In many of the stories, great fun happens when test data or placeholder material goes into production. Such as the titular “Dear customer, You are a loser.” email or the “Rich Bastard” test name in a mail merge. When you’re creating test data, don’t be clever or wry, since that might leak out. Play it straight. And for Pete’s sake, figure out how to purge it before it gets out there.
   
• Review your CMS procedures.
  A lot of the news-stories-that-aren’t-real tales in this book come from instances where content authors somehow put their incomplete works into draft and they end up live on the Web site. This might be because the content management system has issues, or it might be because the content author has the ability to publish his or her own work and inadvertantly does so before the proper time. Sometimes, this happens without a CMS where code roll-ups get promoted with draft content. Regardless, you need to scrutinize those procedures to minimize the chances of this happening. As a bonus, one of the stories is about a journalist whose story gets promoted to the live site with disrespectful placeholders within it. Have I mentioned that’s a bad thing?
   
• Not understanding practices of the users and building in problems through ignorance.
  Then there’s the story about the guy who got a license plate that said NO PLATE and ended up getting the tickets for every car in the state without a license plate. Or at least those where the police officers had written No plate for a license plate number. If you don’t know what your users’ habits are, you can walk right into a problem where their habits conflict with your software’s interface and abilities.
   
• The impossible calculated numbers.
  The book is rife with the stories of impossible calculation results, such as the trillions of dollars in library fines, the bajillions of dollars in water meter charges, and so on. Does your software have a sanity check to flag outlying calculation results? If not, why not?

This book has a lot for the software quality professional to learn. It exposes patterns of failure we need to recognize and to account for in our testing and rolls up a whole lot of lessons learned meetings into a very browseable 300 or so pages.

Definitely recommended.

Books mentioned in this review:

The Diablo 3 servers are at full capacity, preventing many from playing the game.

Players across the globe are reporting “Error 37″ when trying to log in following Diablo 3′s midnight launch in the UK at 11pm last night and, just hours ago, on the West Coast.

“Due to high concurrency the login servers are currently at full capacity,” Blizzard wrote on the Battle.net forum. “This may cause delays in the login process, account pages and web services.

The best part, or worst part, depending upon whether you’re a mere observer or a customer who plunked down $60 for the game: Blizzard actually warned they weren’t going to have enough server capacity to handle their user needs in a blog post last week. And didn’t accommodate the usage spike until it happened.

(Seen via Fred Beringer tweet. I’m not a fan of the video game series. It reminds me too much of my day-to-day work.)

Most of us have to estimate probabilities every day. Whether as a trader betting on the price of a stock, a lawyer gauging a witness’s reliability or a doctor pondering the accuracy of a diagnosis, we spend much of our time—consciously or not—guessing about the future based on incomplete information. Unfortunately, decades of research indicate that humans are not very good at this. Most of us, for example, tend to vastly overestimate our chances of winning the lottery, while similarly underestimating the chances that we will get divorced.

Psychologists have tended to assume that such biases are universal and virtually impossible to avoid. But certain groups of people—such as meteorologists and professional gamblers—have managed to overcome these biases and are thus able to estimate probabilities much more accurately than the rest of us. Are they doing something the rest of us can learn? Can we improve our risk intelligence?

Sarah Lichtenstein, an expert in the field of decision science, points to several characteristics of groups that exhibit high intelligence with respect to risk. First, they tend to be comfortable assigning numerical probabilities to possible outcomes. Starting in 1965, for instance, U.S. National Weather Service forecasters have been required to say not just whether or not it will rain the next day, but how likely they think it is in percentage terms. Sure enough, when researchers measured the risk intelligence of American forecasters a decade later, they found that it ranked among the highest ever recorded, according to a study in the Journal of the Royal Statistical Society.

The excerpt says that you can improve your risk analysis abilities by getting immediate feedback. However, if you’re trying to answer the risk of deploying undertested software with the potential for hidden defects or if you’re estimating the chances of a discovered error occurring in the wild, that feedback might not be immediately available if the circumstances don’t occur until six months after the software is in use.

At any rate, it’s an article worth reviewing and maybe it’s worth getting the whole book Risk Intelligence: How to Live with Uncertainty.

Class, who can tell me what’s wrong with this picture?

Strangely enough, QA does just that.

And, yeah, I am a month behind on the local newspaper. I’m even further behind on the Wall Street Journal, which means when I try to catch up on them, it’s almost like living as Time in Piers Anthony’s Incarnations of Immortality series.

It sounds better really, really loud.

Microsoft’s decision late last year to switch on “silent” upgrades for Internet Explorer (IE) has moved some Windows users to newer versions, but has had little, if any, impact on the oldest editions, IE6 and IE7, according to usage statistics.

Being in QA means you get to say “I Told You So” an awful lot. But it never gets old.

Even the tiniest delay in loading a Web page isn’t trivial. Amazon has metrics showing that a 0.1 second delay in page rendering can translate into a 1% drop in customer activity.

Why is this particularly disturbing? Customers go to Amazon to buy. What is that slow page low time doing to your site’s visitors whose attachment and commitment to your site might be much lower?

By the way, you are doing your performance testing from outside the corporate network to get a feel for the load times on the actual Internet, aren’t you? I’d feel a little silly asking it, except I am a seasoned QA consultant. You might not be.