Live data from Hacker News

Healthcare.gov crashing because backend doomed in the requirements stage

forbes.com

11–20 of 57 posts

Re: Healthcare.gov crashing because backend doomed in the requirements stage

#11
post #7

Could anyone share which platform / framework they used?

There probably isn't any one "platform/framework" they used. This beast touches too many systems, many of which are 'legacy' for the phrase "platform/framework" to really apply.

If it's anything like what I saw at the one (and only) government contractor I ever worked for, the site is a frankensteinian nightmare of COTS ('Commercial Off The Shelf') crap (which federal contracts encourage, when they don't outright require it) and sweatshop-style integration development run by contractors who hire anybody with a heartbeat and a handful of competent people, and pay them all peanuts while billing $200/hr in labor to the government.

Re: Healthcare.gov crashing because backend doomed in the requirements stage

#12

I know the people who worked on this. This is not what happened. Just yet another propaganda piece by Forbes.

Can they elaborate on what actually did happen? If I were your friends I would be trying to contact news agencies with corrections if at all possible because this is shaping up to be the highest profile government IT failure in US history.

Re: Healthcare.gov crashing because backend doomed in the requirements stage

#13
If there is anything that can come of good of my taxes (a ridiculous amount of it in fact) is that we should educate people on the difficulties of software development. This would make a fantastic case study on what I presume are the issues at hand:

- Maintaining complex code (+1mil LOC)

- Classic "waterfall" approaches to software development (and the inherent problem with trying to blueprint requirements up front)

- The mythical man month[1]

- Change management

Funny thing is...these are all human problems.

[1] - http://en.wikipedia.org/wiki/The_Mythical_Man-Month

Re: Healthcare.gov crashing because backend doomed in the requirements stage

#14
post #7

Could anyone share which platform / framework they used?

I'm sure tons. The web site's code is pretty straight forward, it's that interacting with so many other parties that is not (besides anything having to do with actual insurance, Healthcare.gov interacts with the IRS, social security, homeland security, Equifax, etc etc).

I'm not sure what the solution is since these checks are not optional. It would be a huge political scandal if just one illegal immigrant was able to buy insurance using Healthcare.gov and there are surely many groups trying every day to make sure this happens.

Is there any large benefits system that works well? All that I have seen from MegaCorps are also awful and they don't even have all the complex stuff to make sure you qualify (since you work at the company, you qualify).

Re: Healthcare.gov crashing because backend doomed in the requirements stage

#15

I know the people who worked on this. This is not what happened. Just yet another propaganda piece by Forbes.

Per the NYT: "But the government was so slow in issuing specifications that the firm did not start writing software code until this spring, according to people familiar with the process."

Source: http://www.nytimes.com/2013/10/13/us/politics/from-the-start... (October 12)

And from today (Oct 21): http://www.nytimes.com/2013/10/21/us/insurance-site-seen-nee...

In a previous life I worked on similar software development projects at the US State level. This project was several orders of magnitude larger in scope and in complexity than what I worked on. Assuming a generous start date for Spring - say March 1 - this boils down to ~7 months to design and develop to the Oct 1 hard deadline. Nearly impossible in my opinion.

I'm not discounting that there couldn't be issues else where in whole process. These would include: communication overhead between all the various agencies and contractors, integration nightmares, and not enough skilled folks at Medicare to manage all of this. But having the requirements delivered several months before roll-out seems to me a recipe for disaster.

Re: Healthcare.gov crashing because backend doomed in the requirements stage

#16
I didn't see anything that meant it was doomed from the requirements stage.

This was more of an Obama love fest and defense of ObamaCare than a technical article describing who the backend was doomed.

For what this cost to build it could have been much better, much simpler, and handled the scale gracefully.

Yes privacy concerns keep it off the elastic cloud. (not a point mentioned in the article)

Yes authenticated users limit caching and make scaling harder. (not really mentioned)

But when you are talking about everyone in the US, you only have so many combinations. Income in something like 32 ranges, number of kids 1 through 12 (greater than 12 they are all free) a bunch of ages.

We just saw a post that only 15 searches are new to google each day, so the number of combinations is much less than search which does lots of caching.

The requirements were messed up, the implementation was. Clearly not built by people who had ever done "Facebook scale" stuff.

Re: Healthcare.gov crashing because backend doomed in the requirements stage

#17

> In my case, even the most expensive plan for our family in the State of Maine, where we live, is half the cost of what we are currently paying, exclusive of any subsidies. The elephant in the room is that this is not the typical case - http://www.forbes.com/sites/theapothecary/2013/09/25/double-...

> The elephant in the room is that this is not the typical case - http://www.forbes.com/sites/theapothecary/2013/09/25/double-....

It still boggles my mind that people are surprised by this. Mathematically, including people with pre-existing conditions will mean either that those people are required to pay for the (expected, not actual) costs of their own care, or that other people will be required to pay for those costs[0]. This effect is much larger than the effect of mandating insurance for younger, healthier people who otherwise elected out of getting insurance[1].

Note: this is not a normative statement about whether this is a "good" outcome. This is just a a mathematical observation about the way insurance works, from a mathematical and economic perspective.

[0] Subsidies come from taxpayer money, so they have no net effect on this accounting - it changes how the money changes hands, but the money still has to come from somewhere.

[1] I'm waving my hands around the math here, but if people are interested I can dig up the more detailed blog post draft that I did a while back explaining this in full detail.

Re: Healthcare.gov crashing because backend doomed in the requirements stage

#18
post #16

I didn't see anything that meant it was doomed from the requirements stage. This was more of an Obama love fest and defense of ObamaCare than a technical article describing who the backend was doomed. For what this cost to build it could have been much better, much simpler, and handled the scale gracefully. Yes privacy concerns keep it off the elastic cloud. (not a point mentioned in the article) Yes authenticated us…

Well, some reports are that the requirements were changing until 1 week before launch, and that development didn't start until March of this year due to requirements delays. Just those two factors alone would doom just about any project of this scale.

Re: Healthcare.gov crashing because backend doomed in the requirements stage

#20
Wow, this particular excerpt from the article is stretching things a bit too thin:

"Clearly there are problems with the government’s IT procurement processes, but if the same level of dysfunction had been present in the software behind Obama’s political campaign (as it was, apparently, behind Romney’s) the President would have never been reelected."

Really? I doubt the campaign websites were the deciding factor.

Anyway, a lot of speculation in this article...not very insightful or informative.

Post reply on HN