The problems with the ACA/Obamacare website are old news by now, and the discussion is on about what went wrong. Testing was late and only perfunctory; features were being added right up until the deadline; the system was designed for the wrong scale. We get that.
As application developers, particularly those of us who work primarily in the web and mobile space, there are some serious things we should think about. One of these is the increasingly-popular “single page” web app. It’s tempting to keep all the business logic in that single file, but the resulting complexity makes debugging and regression testing tricky. Not to mention that any future changes run the risk of wrecking the whole app.
Apps designed for HTML5 and mobile devices tend to rely on the local SQLite browser database, rather than on the old standard, server-side storage. This is a risky proposition all by itself, for a number of reasons. (When was the last time you purged your local browser’s *database* cache?)
But the biggest problem is that the ACA site times out when you’re working with your data, usually without much of a comprehensible error message.
So you reload your page. But it’s a single-page application. So you’ve lost your place in line, and likely all your input. So you’re starting over again. (Tear out hair here.)
It’s worth it, as developers, to think about where we’re putting our data, on the client or on the server; about round-trip times for passing data; about clean, fast, economical code and data exchange. You know, all those things they used to teach in C class.
See this intelligent discussion:
http://virtualinterworks.com/2013/10/20/healthcare-gov-architectural-lessons-we-can-take-away/
***