What Obamacare Can Remind Us About Websites

As I’ve watched the “fiasco” happen with the Obamacare website over the last few weeks, it has occurred to me that this is a great reminder of two things I already knew. Building websites is really hard. And there are a million potential points of error. But websites are really important. Having built them since … Continue reading “What Obamacare Can Remind Us About Websites”

As I’ve watched the “fiasco” happen with the Obamacare website over the last few weeks, it has occurred to me that this is a great reminder of two things I already knew.

Building websites is really hard. And there are a million potential points of error.

But websites are really important.

Having built them since 1995, you can imagine that I’ve just about seen it all. From the early days, I’ve watched companies have failures over and over again with their websites, their emails and other electronic media. (Just last week, Weight Watchers accidentally deleted a whole day of tracking data from all their customers. Oops!)

How could something like this happen? We have a healthy respect for backups and redundancy, but that doesn’t change the simple fact: it’s hard to develop websites. There is a concept I talk about called SPOF – Single Point of Failure. This means that if one single (even tiny) part of a system fails, the entire system fails.

When an error happens in website development, the culprit is often a Single Point of Failure. Hundreds or thousands of hours are spent developing new functionality for your website. Then you add one tiny thing (usually at the last second), and it breaks the whole system. All those hours are wasted, until it is fixed.

In the case of Obamacare, I understand many of the issues had to do with the number of people visiting the website, often called the “load” of the website. I want to be honest and say that we’ve experienced load issues on websites our team has developed as well (don’t believe anyone who says they haven’t!).

The truth of the matter is it is difficult to test load without actual site visitors. There are computer programs that simulate load, but of course, it’s hard to make a computer do “human” things. You can test loads and try to anticipate, but sometimes the best we can do is to watch it and be ready to turn on a dime if we see load issues.

The second lesson is that websites are important. If you think about how many thousands of hours were spent by people working on Obamacare, and the very last step was putting the information on the website and allowing people to sign up. And that’s where it failed.

It was very much a Single Point of Failure. All those hours were wasted, and the people working on it lost credibility, all because the very last (but incredibly important!) step of the process went awry.

Back in the early days of web, we thought errors were big problems. But online issues have only increased in importance. Now, when something goes wrong it is often mission critical.

My theory is that this is why Software as a Service (sometimes called SaaS), like Saffire and many others, has gained in popularity. It takes some of the risk away because there is already a core platform that is incrementally added to, rather than creating it from scratch. It doesn’t completely eliminate the risk, but it at least mitigates the potential points of error for a very important part of event and venue marketing, the most important virtual front door for an event, their website. And for us, that’s a good thing.