By now, we all know that the website for the “Affordable Care Act” (aka Obamacare) is a mess. Not “was a mess”, but still is, 3 weeks after it launched. Here’s an article with screenshots, and comments on various errors encountered.
As programmer, a major lessons can be learned from this failed rollout:
- Make it work – even though the initial failures were blamed on the high volume of users, it’s become clear that there are functional problems with the code and databases. If it were purely a capacity issue, after a few days that would have subsided as the volume decreased. Instead, problems have persisted. Now we are hearing that the whole thing might have to be rewritten and insurers are complaining about getting mangled data from the system. Luckily, the government has a monopoly here, and “customers” have no where else to go. If you launched your website in this way, you’d be finished. If the site isn’t ready, delay the launch until it is!
- Make it simple – in order to see any pricing for the various plans, you need to give pretty much all your personal and family information. That means many screens of data entry to get to the pricing. Any e-tailer will tell you this is a kiss-of-death. You need to show customers the pricing up front, including shipping, return policies, etc. Nobody wants to go through a lot of hoops only to find out they don’t want to buy. Again, in this case consumers don’t have a choice, but in the real world you can’t operate that way.
- Settle on the design early – one complaint I heard (and I believe it) is that the programmers on this project were dealing with constant changes to the requirements – requiring whole sections of code to be rewritten or discarded. While it’s important to be flexible on functionality, at some point (long before the launch date), you need to make solid decisions and stick with them. Better to launch with an imperfect user interface, than to launch with something that is buggy or doesn’t work at all.
- Beta test – big companies like google and facebook routinely “roll out” new features to a select group of users, usually by invitation only. Then after a few weeks, they expand the rollout to everyone. I didn’t hear about any such rollout plan for healthcare.gov. Instead, they chose the “Big Bang” approach – and when the big day finally came, we got a big “thud” instead.
- Don’t forget Security – I’m not sure the healthcare.gov site is “insecure”, but I worry that it is. Why? Because all the errors suggest that the programmers were scrambling to fix basic bugs, and functionality errors. That means that any “security testing” that was done was incomplete. It had to be, because the site was changing up until the last minute. It’s like inspecting the wiring in a building while the electrician is still there working. You can see what’s been done, but you can’t vouch for what is not complete or needs to be changed.
Many of these may seem like common sense, but it’s easy to lose sight of these when you are working on an exciting new opportunity. It comes down to simple execution of the fundamentals. The internet has matured to a point where user expectations are very high – so make sure your site meets them.