Could Better Testing Practices Have Prevented the Healthcare.gov Defects?
blog.smartbear.com
blog.smartbear.com
http://www.usatoday.com/story/news/nation/2013/10/05/health-...
Didn't that site cost millions to make?
Wait, is this blog entry trying to sell their own products?
This is a better round-up of stories about the website:
http://www.theatlanticwire.com/politics/2013/10/obama-admini...
Not sure why this one finally made it, heh.
Creating a website that can handle, well, nearly the entire country, out of the gate, is not trivial. (Facebook etc got to scale up to that level, they didn't need to do it out of the gate). But it also can be done.
How? Well, you hire real experts in doing this sort of thing. And you give them enough calendar time, and enough billable hours, to do it right. And you don't give them your own 'business requirements' which contradict their expertise on what's neccesary to make it work.
Obviously the government did not do one or more of those things, right?
(I will confess that my opinion is not high of the likely expertise level of typical IT government contracting firms.).
Gov't contracting is, in economic terms, a rent-seeking business. The best and brightest in a given contracting firm are dedicated to pursuing new work. I work for a contractor, and my fun IT projects are all proof of concept items. Stellar execution simply isn't rewarded. The gov't puts idiots in charge of things: not idiots in the sense that they aren't smart, but idiots in the sense that they have no expertise in anything. They are hired for paper qualifications (ever heard of a Project Management Professional cert? It's what they hire, and its useless), and the bright/motivated ones move on to interesting work, perhaps in other parts of the gov't, or the private sector. I built a great tool, using all open source technology for the gov't once. I built it in 3 weeks (it is now officially gov't owned software), and it replaced an $80K piece of software (commercial off the shelf) that was inadequate for the task. My reward was complaints that the security people weren't familiar with Postgres, and an immediate request to migrate to Oracle. There was no functional reason for this, but I complied after the gov't shelled out huge sums of money for Oracle license. Why? Because paper pushing idiots in the gov't are in charge of IT security, and their credentials for the job are based entirely on passing certification tests. Their entire incentivization at their job is to minimize their own workload, rather than maximize the happiness of their gov't customers.
Do you think anybody who could even guage whether proper testing was being performed or not was in charge of this project from the gov't level? Of course not. If they had, it would have been properly tested.
I'm mad as hell about this because I want the ACA to succeed. I don't think its ideal, but its vastly better than the existing system of hospitals as clinics for the uninsured hordes.
The Federal gov't has an awful hiring process, and until it is fixed, you are lucky to encounter competent and driven individuals within it. You are foolish to expect it.
I couldn't agree more. You only get one chance to make a first impression and they blew it. (sigh)
I mean, let's start admitting that it's _not_ easy to make a site that can handle that level of traffic. It's do-able, but it's not easy.
Once they have it handling the proper traffic, only _then_ are they going to start finding out about all the bugs that are actually logic related instead of load/traffic related. Which I'm sure there are plenty of, because all software has bugs, and because the QA for those (including integration with IRS system or whatever?) isn't trivial either, and I'm sure they didn't do any better with it then they did with preparing for the load.
Also, it would have really helped to have someone - likely not a developer - to bridge the gap and ask the customer "do you really need people to set up user access before viewing plans or you just want that? why?" and then turn to the developer and say "ok, what does that mean technically? what the pros and cons?"
"A scrappy little startup working out of a DC garage that completely influenced the course of how the web-facing portions of the Affordable Care Act were to be implemented"
Subsidy is based on income, and it's simple enough that NPR and others have already build subsidy calculators. Put that in javascript and you've still got static pages, running calculations client-side.
In Maryland, our exchange website is poorly designed and written, just on the frontend (I obviously can't see the backend), but at the same time, all of the frontend issues could be fixed with a clever caching scheme.
Where the real bottleneck almost certainly lies is when the system takes your user submitted data and has to post it into what is surely an old, legacy federal system so that it can verify your identity. That old legacy system may have seen upgrades in preparation for this, but probably not -- even so, there's simply no way to prepare for the onslaught of users accessing (indirectly) what was certain to have been an isolated, government-only database in the past.
You can't see what's running at the moment of course, but why shouldn't you expect to be able to see the source? Why are new government IT projects closed source?
The biggest improvement they could make in the short term is setting up a light weight version so you can just enter the needed information to view your plans/options prior to the signup/verification process. Then once you've decided on a plan go into the signup process.
A lot of traffic is probably just people comparing prices, deductibles, etc putting unnecessary strain on the signup system.
It seems odd that you can't even view the log in page when you click log in on the home page.
Definitely looking forward to details about the site, backend, db, hosting, traffic, etc . . . once everything shakes out.
Washington's site did just that. Still blew up. For the first couple of days, just trying to get available plans didn't actually work.
There aren't that many websites out there that experience the kind of traffic levels the exchanges have. Those that do have mostly grown (if sometimes quite quickly) to those levels, not launched with them on day 1.
Competent people with prior experience scaling to these levels are (over-)employed with high compensation. They didn't work on these sites.
The specs were not exactly realistic on number of users at a time. Heck, even Apple still gets slammed and they know its coming.
Plus, the experience just isn't in the DC contracting community. They can do websites, but not high availability transactional. If we were talking back-ends, then yes they have high transaction experience, but not with websites.
I will be expecting second (third?) day stories about bad data problems and failed transactions. This won't be a simple thing.
1. Load test, discover issues. 2. Fix issues. 3. Repeat steps 1-2 until no more issues.
That is the flabbergasting part. Nobody actually tried applying real load to the system before release? It fell over so easily and quickly the only assumption is either no loadtesting was performed, the results were ignored, or massively incorrect load numbers were used (all of which are signs of incompetent mangement).
FWIW, I don't think the issues right now are load so much. I think there's some insanely bad logical pieces that are messing things up, and possibly have corrupted accounts that were created early on. I base this on a few things.
1. The "username" requirements.
The username is case sensitive. Choose a username that is 6-74 characters long and must contain a lowercase or capital letter, a number, or one of these symbols _.@/-
Really? I know some systems use case-sensitive usernames, but given that you're already forcing some odd characters and whatnot in there, why not normalize to lowercase? This just feels like it's going to cause more support problems (mobile safari automatically uppercasing a username that should be lowercased, etc).
Also... the English description of that username is nowhere near intuitive. "A lowercase or capital letter". As opposed to what other kind of letter?
2. Multiple accounts with a single email address.
I've been able to 'successfully' register multiple different username accounts with the same email address. When I do a password reset based on email (the couple times it worked) which username was I resetting the password for? I say 'successfully' because no login attempt has ever worked. And now trying to register yet another username with the same email address doesn't work, but the error message is so vague ("there was a problem" IIRC) that I can't tell if that was a factor or not.
OK... 2 things. That's about as far as I've been able to see in to the system so far, so that's all I can judge it on. But it seems that they've probably allowed some logical inconsistencies in my own signups that may be causing more problems now, and I don't think they are related to load.
Of course, I could be 100% wrong, but it doesn't feel like load is the culprit right now.
For example, there is a lot of caching you just have to do. Tons of it. Cache as much as you can. Memcache and Varnish are your friends, use them as much as you can. Unfortunately, if Healthcare.gov was in a very write-heavy situation, they are somewhat limited in how much caching will help.
One thing they could have done that would have saved A TON of load is not require users to sign up before giving them a list of available plans. That whole part didn't need to be database driven at all. The data could have been stored in redis and they could have used javascript to filter it based on a form. That would have been ridiculously fast. They also could have prerendered all the plan list possibilities and stored those in varnish. That also would have been ridiculously fast. My guess is millions of people just wanted to check prices and eliminating the database load for those users would have probably kept things running fast and smooth.
Slow DB queries are the enemy and you don't realize how bad they are until you are at scale. Sure, it only takes a few seconds on your local machine, but multiply that times thousands of concurrent users and your DB gets swamped. If you are using an ORM, it is MUCH harder to track down where in your code that 3 way join that scans every record is happening. Ideally you'd be using straight SQL and maybe use comments to tag a query. Also tools like newrelic might help if only because many databases don't offer great visibility of performance data.
Sharding your database is something that is probably possible, and in the case of healthcare.gov, they probably could have had totally separate infrastructure on a per-state basis that would have made scaling a lot easier than putting everything on the same database. Also, put reporting and things that aren't mission critical on a slave database. The last thing you want is a reporting job bringing down the live site in the background.
Getting good hardware with fast IO is going to save a lot of developer time required to scale things. Using fast SSD's is probably the easiest win to speed up your database. Developer time costs a lot more than hardware and giving yourself cheap headroom up front gives you breathing room on launch.
Performance testing is also something worth doing, but the tricky part is until you roll out, it is hard to know exactly where the hotspots are going to be. In this case, new user signup would be the obvious place to test, so they probably should have tested up to the limits of their servers and tried to extrapolate an expected number of users and maybe increased that by 1.5x or something to have some leeway.
On a rollout where you don't know what you are getting into user wise, being on a cloud where you can scale out fast as demand requires is something worth doing. They could have saved a lot of bad press and headache by being on the cloud initially and migrating to less hardware after the initial peak died down.
There are a ton of little things like that you have to think about if you are dealing with massive scale. I don't know if the engineers building healthcare.gov had ever dealt with something like this before, but I'm sure they're learning these lessons now.
That's all I wanted to do (I have employer-based coverage for now). I turned back once I realized you needed an account to see this, but assumed it was due to some policy issue or agreement with the insurers.
1. Slow Query Log 2. Grep commands
Scaling databases is hard,developpers like ORMs , but ORMs make scaling databases even harder.
ORMs aren't bad on principal, imho... but they give you more than enough rope to hang yourself while promising a magical efficient user-friendly rope.
This would not be a particularly difficult feature for an ORM to implement.
It offered a manual "Load" operation that manually initiated the lazy load for a given FK relation, providing a worst-of-both-worlds option.
The thing I could never figure out in LinQ was how to make an explicit load of related objects fetch more aggressively. Like, say I have object Foo. I find out I need Foo->Bar, but realistically I'm also going to need Bar->Baz and Bar->Quux to make Bar useful. I could make a stand-alone query to pull down Bar, Bar->Baz and Bar->Quux in a single query, but then Bar wouldn't be loaded attached to Foo, and if I attached it to Foo it would confuse the object context. I could use the Foo->Bar to load Bar, and then Bar->Baz and Bar->Quux to load Baz and Quux... but that would be too many hits to the DB. I could never figure out how to put those things together, and fetching Foo->Bar->[Baz|Quux] proactively every time I wanted a Foo wasn't preformant.
Of course, this was back when I was obsessed with normalization and was using UUIDs for all my primary keys, so I might be missing the point.
But to be picky, let's note that "manually initiated the lazy load" -- there's nothing "lazy" about that load, heh. The "lazy" part specifically means "on-demand, as asked for, automatically."
In ActiveRecord, you can quite easily set 'eager loading', which is setting certain loads to batch for efficiency, like you're talking about -- and this can apply to lazy loads (when you lazy load X, ALSO load y and z together, in as few SQL statements as possible), OR to manual loads (right NOW, load x, y, and z together in as few loads as possible). But AR doesn't let you turn off lazy loads, ha.
One question would be whether they hired people/firms who had had to deal with that level of scale before.
I'd assume not.
But apparently they hired someone who didn't even know enough to know that they were not qualified to do it.