Healthcare.gov problems
published on 2013/10/07
The US Federal healthcare exchange marketplace is a good example of the difficulties in implementing a system based on a fixed deadline (October 1) and high minimum requirements. The source code of the website is available online at https://www.healthcare.gov/developers/
Netflix have spent the last 10 years perfecting and redesigning and rearchitecting very good user experience. This is very new. It will take time to get to that level. It could be there in six months, but I wouldn’t expect it to get there in the first step.
This remark is apt. People naturally compare a well run established software to a new product however the time spent on a product does matter on certain quality aspects of software. You cannot compare your brand new 6 months project (with limited budget) to multi years multi million dollars sites like Netflix or Facebook.
A well maintained software does gets better with age.
The user interface, or frontend, of healthcare.gov is quite interesting. It’s design has been compared favorably with top commercial sites. It was implemented using modern web development techniques, working well across browsers and on mobile devices. We used similar techniques on the president’s campaign: generate static files from templates with Jekyll, serve them from behind a CDN (Akamai, in the case of healthcare.gov). This gives you a very fast, low-latency user experience that’s very durable in the face of high-traffic loads. Dave Cole has written about the process by which the frontend was developed, it’s fascinating to read if you have any experience with how government sites have typically been built. And you’ll notice, no one has complained about being able to access the site itself. healthcare.gov itself has been up continuously since October 1st. It’s submitting forms back to the server that’s been the issue. TPM This highlights the importance of getting all the components in your flow to work properly. People demand that their whole experience to be smooth and painless.
The bottom line is this:
- Be flexible with your launch date or be flexible with your launch requirement. You cannot have both.
- A failure to conform to the first rule will compromise the quality of your site.
- Continue to develop your software past the launch time and pay attention to the quality of the source code/architecture of your system. A system is more than just its number of features. Invest on improvement on the infrastructure of the system itself so it is capable to handle your business demands in the future.
This has been proven again and again in the history of software development.