5 Websites That Crashed This Holiday That Could Have Been Avoided

T’was the season to deliver a seamless online user experience, to bring under two second response times to shoppers looking for the best pre and post Christmas sale. Except that it wasn’t. At least not for the following five companies.

Every Christmas, e-commerce, ticketing, flash-sale and other online businesses prepare themselves to meet the demands of expected visitor traffic. Most fair exceptionally well because they take the necessary precautions and run realistic load and performance tests well in advance.

Yet, as more and more traditionally offline services move online and consumer demand for faster response times increases, the post-mortem on websites that crash during the holiday rush draw ever more media attention.

The increasing media attention is also due in part to the fact that innovation in performance testing has dramatically reduced the cost of doing so and the proliferation of cloud-based tools make testing services accessible to every website owner within just a few minutes. Basically, there is really no excuse for crashing.

Here’s a recap of some of the websites that crashed on our watch this holiday. We definitely didn’t catch all of them, so please do share your stories in the comment section below. Moreover, as we are a Swedish based company, many examples are from Sweden. Feel free to share examples from your countries.

1. December 4th, Wal-Mart.com:

Wal-Mart went down for a brief period, about an hour, on December 4th. Admittedly, they did claim to have had over 1 billion views between Thanksgiving and Cyber Monday and to have had the best online sales day ever on Cyber Monday.

So, despite the brief downtime, we’ll give it to Wal-Mart. They did have a pretty massive load to bare and if anyone can take it and recover that quickly, it’s probably them.

Read more 

2. December 16th, Myer.com.au:

On boxing day, Australia’s largest department store group, Myer, suffered technical difficulties that prevented online purchases during the biggest shopping day of the season.

According to the media, Myer has pumped tens of millions of dollars into improving its website over the years. Despite boosting its technology, this isn’t their first crash during peak shopping periods. They also crashed in June when heavy customer traffic triggered a website failure half an hour after the start of the annual stocktaking sale.

Although Myer is pushing an omni-channel strategy and hoping to boost its online sales in the long-term, the website is only responsible for about 1% of the company’s business today.

Although online sales may not make up a significant part of business today, it would be wise not to deny the impact these constant crashes probably have on the successful implementation of an omni-channel strategy. Yet this is how Myer CEO, Mr. Brookes,  seems to be behaving when he made this odd statement about the recent boxing day crash.

“There will be no impact at all on our profitability or our overall sales”

Sure Mr. Brookes, if you say so.

Read more

3. December 25th, Siba.se:

The day after Christmas, Siba – one of Sweden’s largest electronic’s dealers –  crashed due to overwhelming visitor traffic. This in turn led to a social media storm of customers complaining that the site was down.

As a curtesy to those who were not able to access the site,  Siba directed visitors to its sales catalogue saying: “Oops, at the moment there is a lot of traffic on the site, but you can still read our latest catalogue and stay up to date through our Facebook page”.

Thanks Siba, reading about the sales I’m missing out on is totally the same as taking advantage of them.

4. December 29th, SF.se 

In the period between Christmas and New Year’s,  SF  – Sweden’s largest movie theatre chain – suffered continuous day long crashes and delays. This left many people unable to fill those long cold days, when not much else is going on, with a cozy few hours at the cinema. In fact, these “mellandagarna” (days between Christmas and New Year’s) are the busiest movie going days of the entire year.

Needless to say, people were very frustrated. Particularly because SF has a monopoly and if they go down there is pretty much no where else to turn to get your cinema fix.

Read more

5. January 1st, Onlinepizza.se:

For the third new year’s day in a row, Onlinepizza.se crashed due to heavy user load. This may seem trivial to some, but to Swedes it’s devastating. That’s because on new year’s day, Swedes eat pizza. It’s just what they do.

So, despite the nearly  30,000 or so pizzas sold that day through Onlinepizza.se, many hungry swedes were forced to brave the cold and wind and buy their pizza the old fashion way – in a pizzeria.

Read more

Some of the holiday website crashes described above are bearable; most of us can go without buying another electronic device or pair shoes for at least a few days. But not being able to cozy up in a warm cinema on days when it’s to cold to go outside and nothing else in the city is open is just disappointing. As is not getting a home delivered pizza when you just simply can’t stuff another left-over Swedish meatball down your throat.

The Demise of Healthcare.gov and the Importance of Testing

Most people have probably already heard about the less than successful launch of http://www.healthcare.gov, often colloquially referred to as the ‘Obamacare website’. Bloggers and news agencies quickly jumped on the bandwagon to point out every piece of available evidence that this project is deeply flawed in every single way. Fingers have been pointing and names have been called. And let’s not start talking about what ObamaCare’s political opponents have said.

Certainly, there are plenty of differing opinions out there about what went wrong: Some will say that this is a reinforcing evidence that large software projects with too many people involved is a management nightmare that almost without exception, ends in failure until it hits version 3.0. While others will tell you that this is simply an expected outcome whenever the government embarks on just about anything. A third group will point to specific technical flaws that have emerged and it’s a clear indication that both management and the software engineers involved are simply bad people making kindergarten level mistakes.

So, what has this got to do with load testing? Quite a lot actually. As the makers of a very popular cloud-based load testing tool, we’ve always been advocates of tools and methodologies that leads to good and verifiable software quality.

Admittedly, we specialized in performance testing, but in this case it goes beyond that. Our opinion on what went wrong and what should have been done takes a non-political stand, in fact it’s pretty much neutral on development methodology and we definitely won’t call names. Just like in politics, our opinion boils down simply – it’s all about priorities.

Take a minute to think about the phrases ‘software quality’ and ‘verifiable software quality’. That additional word in the latter phrase means a lot and it changes everything. I can safely bet that this is something 100% of all software project managers covet, I mean, who wouldn’t? Yet it’s safe to say that less than 50% of all software PM’s can confidently claim that their projects have achieved it.

And why is that? Well, we’ve discussed it before here, when we briefly commented on our State of Web Readiness study. To begin, software quality doesn’t automatically materialize out of thin air in a project just because you have hired the crème de la crème of developers (how would you even define that?), let alone even the most experienced developers.

You will have good software quality if you make it a priority; not with a mere ‘Should-have’ but a ‘top of the line, grade A must-have’ type of priority. Then, when you’ve decided that quality is top priority in your project (again, who wouldn’t?), adding the concept of verifiable software quality is another leap.

Going from the intention of developing good quality software to measuring it is a big but essential step. A lot of development organizations around the world have taken this step and I would be surprised if any of them regretted choosing it. Surely, it involves some form of upfront investment to do it correctly but once you’ve taken the initial steps, your project will benefit from the fruits of your labour.

I’m sure that what I’m saying here is not new to anyone involved in the healthcare.gov project. In a software project north of 500 million USD there’s bound to be many software quality assurance tools in place already. If I should guess, I’d say that the problem with the healthcare.gov project was a problem of test coverage. Evidently, some areas weren’t tested at all, while a large portion of the project hadn’t been tested in all aspects as it should.

What about performance testing? Well, it should be obvious that a system that needs to handle tens of thousands of concurrent users needs to be tested for performance in general and specifically to be tested under load; not just at the end but throughout all development cycles.

In the news we’ve read about an internal 100-user test that was done just one week before launch that managed to bring the site down. It is apparent that load testing the entire site hadn’t been carried out correctly, or worse, not at all.

To round up, I will offer two pieces of unsolicited advice to the entire team behind healthcare.gov:

Number one, don’t panic! Panic is probably what brought you into here in the first place.

Secondly, commit to verifiable software quality and use tools. Tools that measure how you’re doing, tools to verify you’re on the right track and to help you find unacceptable quality. And when you realize you need a really good load testing tool, give us a call.

By: Erik Torsner (@eriktorsner)