RSS

Your website sucks so lets blame your webhost!

Mon, 16th December 2013, 21:58

Unless you've been living under rock for the past few months, you've probably been acquainted with the unmitigated disaster that was the Healthcare.gov rollout. Over the course of these excruciating months, just about everything has been used to explain the collapse of the project: most recently, the discussion has focused on hosting.

HostJury tries to remain neutral and allow users to critique the webhosts but occasionally we are known to make observations (editor's note: okay so define occasional). So there's evidence that Hewlett-Packard dropped the ball when it came to their readiness for the surge of new visitors. But is that really the key issue here?

There are any number of things that can go wrong in the course of creating and maintaining a website. It's easy enough to blame your woes on a poor host, but you have to understand that sometimes, when your website sucks- it might just be your fault. Let's look at some of the ways Healthcare.gov failed independent of its host.

1. No cohesion

Two blind men are are in a room with an elephant. "It's a snake!' says the first man, touching the trunk. "No, it's a tree," says the second, hands around one of the legs. The elephant ends up stomping them in the next midterm elections.

One of the central problems with Healthcare.gov is that it was created piece by piece, with little or no communication from one contractor to the next. This is rarely a good way to put together any sort of project, much less a complicated site at the very heart of a key policy initiative. The whole is more than the sum of all its parts. When you put together any site that intends to do more than one thing, it's critical that you get all the features working AND working together.

2. How Not to Save Face

Not all of the problems in website design are structural- its unquestionable that one of the failings of the Healthcare.gov website was simply a failure to communicate. Henry Chau's July emails reveal an entirely justified terror at the project's fortitude, and yet the very day after airing those concerns, Chau appeared in front of Congress, under oath, to say that things were going well.

It's far too simplistic to blame Chau primarily, of course. The entire situation reeks of expectations trumping the truth. If your website is a project that involves the delegation of tasks, it's incredibly important that the people you're working for feel entirely comfortable with their errors. Websites are fragile things. You should expect them to break over and over again before they truly work. The inability or the unwillingness to admit systematic issues with the website turned what could've been a mildly embarrassing delay into a defining mistake of an entire presidency.

3. On Checking Your Work

A deadline is a wonderful thing, of course, for keeping projects in line. No one could imagine doing without them, but the example of Healthcare.gov should clue observers in to a simple fact: lack of adequate time for testing is just as good as planning to fail. When things go wrong, it's easy to blame something nebulous, especially when you haven't put in the hours necessary to find out what the problems are on your end.

In summary, before you think of blaming your webhost, consider the structural areas in which your own website design might have flaws. And before it gets to that point, go about your projects in a way that accepts criticism, that budgets itself time for improvement, and that has a clear avenue of oversight, so that all the pieces fit in with one another.

Lightning Base. Reliable Managed Wordpress Hosting