500m Lines of Code Suggests Healthcare.gov Will Not Be Fixed Anytime Soon
slate.com
slate.com
Even if this information isn't accurate, I'd argue the figures fall somewhere near what is being said, and still way more than it should for line count and price! That's simply a colossal, and pathetic failure, no matter which way or how you look at it. Why is everyone being so lax on all this? I don't want to say it....but if this was Bush's legislation and administration....yeah well I said it
However, not knowing the exact requirements for the project, we can only speculate as to what the true complexity is. Perhaps the insurance companies in each state did not provide well-documented REST APIs and you had hundreds of custom screen-scrapers pulling the data. Or, perhaps $30 million went to paying all of those insurance companies to build the required APIs? I cannot imagine how difficult and frustrating it would be to interface with those systems. Plus, all of the privacy and data safeguarding practices, and then arranging hosting, etc, etc, etc. Was there waste? Most likely. Was there waste to the tune of tens of millions? Couldn't say. However, to dismiss it as a simple CRUD app might be belying the complexity underneath.
All those sources of inefficiency are, to me, consequential of the fact that the people doing this work don't have proper incentives. $90M for a failed website that has to be redone? Well it's just tax dollars, let's suck in some more.
If any private company were to perform like this, they would be obliterated and their work would be done by people who are competent.
However, that is really here nor there. I am always hesitant to make an armchair judgement about the execution of a development project without all of the facts because there are so many places where things can go pear-shaped. That is basically my point.
I am not sure if so many LoC is even possible to be produced at such short time.
This "one specialist" is obviously a fraud.
Who built this website? What stack is it running on?
Some chunks are made in node.js: https://github.com/STRML/Healthcare.gov-Marketplace
They've taken down the source on github, though it used to be all there. The server they're running it on is AkamaiGHost, and likely linux (although I've heard they're running some on it on windows)
It's an odd choice of technologies. For scalability I would have chosen something that scales across the cloud easy. I'd put my money on the different calls between organisations being at fault. There seems to be many API calls going on. It would take only one server to be slow to cause a cascading affect.