The release of HealthCare.gov and its subsequent failure is not something that most web programmers would be very surprised about.
This has nothing to do with 500 million lines of code, which is bull anyhow, but instead has to do with the organization of any project of the scale, and what most people would anticipate how the government runs code projects.
There are probably some groups within the government, particularly within the military, that run awesome and would put most private enterprise groups (including my own) to absolute shame. However, with HC.gov, we knew that we were dealing with a new team, new objectives, in an untested user market. So that team was going to be green in their field regardless.
Furthermore, we knew that this green team was going to have to scale up immediately. Consider a large application like Facebook. Its user base did not show up on day one. It's feature set, for all it's photo and tagging capabilities was not even close to what it was in the beginning. Facebook was something that a motivated developer could design and test with a small group, making incremental improvements as the software was used.
Not so, for HC.gov - everything had to work day one. What happens if you need to udpate the system? You can't - it's just gotta work.
This is not how most web applications are developed. This is how a lot of desktop applications are developed - basically, choosing what bugs to ship with. And this makes fixing the problem, "A website should just work" a real problem, because there is no version 2.0. This is now and now it should fucking work.
What those of us in this industry could not have known is another most common problem of green teams - a lack of testing.
As so many books on testing will tell you, you are not down with something unless it passes a test. I would say "the home page loads" or "A new user can sign up for insurance" would be a pretty big deal of a test to pass. A beginner tester might note that sign-up is not something that would ever be one test, and that's more to the point - the failure of that intergration is obviously something that would have most likely thousands of smaller tests behind it. You wouldn't even get the chance to test that larger one if those other tests didn't pass. So yeah, obviously someone skimped somewhere.
And take note, none of this has to do with benchmarking tests or the like. But if processing applications was just hung up by performance, we could run that by hand at 3am and gain success. And fixing it would be like AOL - the government would spin up more distributions and db backups, something pretty trivial at this point in time. To my knowledge, that isn't the issue.
Most often when you're trying to trim costs, TDD and adequate QA is not done. Therefore, it would be no surprise that this is where fat was cut, but they weren't cutting fat, they were cutting meat.
I'm not a behind-the-scenes coder who could actually verify these issues, but it doesn't take a big leap to guess and take heed of the troubles a disaster of this magnitude demonstrates. The President looks incompetent and his opponents look spot on correct in that the government is incapable of providing healthcare.
The truth is that the last point has not even been demonstrated - the government and the Obama administration just didn't produce the software to provide healthcare, and really it's gotten to the point it really makes no difference.
Thursday, November 14, 2013