I think the root cause of both this and the healthcare.gov failure is Gall's Law:<p><a href="http://en.wikipedia.org/wiki/Gall's_law" rel="nofollow">http://en.wikipedia.org/wiki/Gall's_law</a><p>The problem with dealing with the government is that they have a long list of requirements that they absolutely <i>must</i> have. As a result, the programmers will work to satisfy all of those requirements, and will let the unwritten requirements (like, oh, "must not fall over when more than a dozen simultaneous users connect") lapse. Frequently with software you <i>have to</i> trade off requirements against each other; when you go to implement it you realize that what the customer actually wanted is self-contradictory. The essence of good product management is being able to make these trade-offs smartly.<p>One thing that all the big companies realize is that to build a large working system, you have to start with a small working system, and then evolve it so it keeps working at all points. Google doesn't dictate exactly how the product is going to turn out at the end - it sets a general direction and product statement, and lots of individual product managers or tech leads then work on figuring out the details.
This was never a technology problem -- it was a business problem. Extremely complicated industry dealing with legacy infrastructure, data, and processes with sprawling, out of control requirements.<p>As context, take a look at Alabama's RFP for their health exchange. [1] It's 286 pages long. A version of it was issued just a month earlier. And this is just the RFP -- I assume the product spec was longer, much more detailed, with changes issued right into summer 2013 or later.<p>[1] <a href="http://www.aldoi.gov/PDF/Consumers/FINAL-Alabama-HIX-RFP-v47_acceptedchange.pdf" rel="nofollow">http://www.aldoi.gov/PDF/Consumers/FINAL-Alabama-HIX-RFP-v47...</a>
As an Oregonian, this whole episode irritates me to no end; the fact that I'm shoving an application into this meatgrinder is just insult piled onto injury.<p>State and local governments should learn from this and other episodes ( our failed DMV upgrade from a few years back for instance ); that an RFP and a procurement process that eats 5% of the budget before anything actually happens is bound to betray the public trust.<p>While I'd like to think that there was an easy solution; say appointing an 'implementation czar' and requiring open source solutions be the default. I don't fool myself as to the likelihood of that working any better.<p>Governments are human nature magnified and focused and as such they have all the human frailties; not to mention that everyone involved is pushing and pulling in a different direction.<p>That said; I do believe that all government IT projects should be open sourcing everything they do or have done for them ( not the data, the functionality ) so that it is open to public review and provides the possibility for public improvement.<p>At the very least if that $43 Million had been spent on something that left a github repository behind; Oregonians would have something to show for that money...
I think the lesson to take from this whole fiasco is not that anything the government does is bound to fail, but that the redundancy offered by multiple <i>competing</i> entities trying to do the same thing is valuable. Everyone here knows software projects have a high failure rate, especially those with complicated specifications. Trusting something as important as a national health care system to the success of one project seems insane to me.
I swear I am astonished that they didn't just tell Zynga to build it, call it 'Healthville' or something, I am sure my Facebook feed would fill up with "Jimmy Can't Sign up for Colon insurance unless he can get 8 friends under 40 to sign up with him, click here to sign up for Jimmy!"
Two issues came up during congressional testimony that I haven't seen discussed are (1) the constantly evolving requirements and (2) the lack of security. I don't know whether the Oregon site has security issues, but the evolving requirements would likely affect both the federal and state sites. According to the testimony I heard, the 2400 page law resulted in tens of thousands of pages of regulations, which were still being codified up until September of this year and impacted site requirements. If this is true then it's little wonder the project failed.<p>BTW, as an Oregonian myself, I find it irritating that the site doesn't work but we are still being subjected to the truly awful Cover Oregon ads (see <a href="http://www.youtube.com/watch?v=Xv2UUcXCo9g" rel="nofollow">http://www.youtube.com/watch?v=Xv2UUcXCo9g</a>).
I'm not real thrilled with their use of Oracle as an example... If you've used Oracle you've probably done it wrong is kind of a mantra for me, anyway.
I'm not sure how this is significantly different from the Federal government's approach. Both hired Big Data. There was little to no accountability during the process. In the end, neither product was delivered because the consequences of nondelivery weren't, well, consequential.
40 million? Thats just for one core of the database! Oops, we forgot to tell you about that? Gee, I'm really sorry. Have I told you about our Spatial Extensions?
These things drive me crazy, 40 million $? I'm sure half of the people here in HN if not more, would do it twice as good, twice as fast, for a fraction of the price.<p>On the other hand, I've worked with tough clients that want a solution "for everything" and force the vendor into a rigid waterfall / BDUF but in the same time keep changing the requirements as they go.<p>But come on, for 41 million dollars you can develop it as static pages, that get submitted to mechanical turk and will have change to operate this for years... I don't get the math.<p>I'm in the wrong business, I should start applying for government contracts.
Anyone here working for Fortune 500 company's IT department knows that hiring companies like IBM global service, accenture, capgemini to do large IT projects is like rolling dice on craps table. Large private corporation's procurement process isn't any better. Anybody here ever had to deal with PEGA systems? :shudders:
I wonder how the math works out.<p>If you assume that each dev has a salary of $100k, they're probably costing the company $200k for benefits, office space, etc. so $40 mill pays for at most 200 years of dev time.<p>Add in managers and a profit margin and $40 mill probably buys you a team of fifty devs for two years.<p>That doesn't sound too absurd. They may have failed, but $40 million seems like the right ballpark for a healthcare exchange.
I dont really understand why you guys dont get mad at your taxes beung thrown like that. Last time something like this was to happen in mexico this happened: <a href="http://techcrunch.com/2013/04/14/bringing-down-the-mexican-mafia-how-mexican-hackers-stopped-a-93-million-fraud/" rel="nofollow">http://techcrunch.com/2013/04/14/bringing-down-the-mexican-m...</a>
I'm honestly not sure why a better health exchange couldn't be built by practically <i>any</i> team. I've kept hearing on NPR that one of the big problems is that they 'needed to make it talk to X number of other government/insurance service'. Have these people never heard of REST or JSON? The problems that the health exchange is facing <i>seem</i> to be largely solved problems and not ourside the realm of reasonable scalability. I'm good, but not amazing at development, and I think I could make Postgres do that is needed for this within a week or two.
Give it to a dying start-up. They'll certainly pull it off with cutting edge technology & tools with great eye for UX, which usually giants fail to do.<p>This will give them a runway till take-off.
I read this and I hear every experience I've ever had on government contracts: a bunch of entrenched liberal arts majors who-know-what-these-computer-things-are-about on the governments' side thinking they can throw money and jargon on literal paper at a bunch of fresh-out-of-college interns hired by the company owned by the government's project manager's college roommate, getting pissed when the programmers don't understand their acronyms and 20 year old paper business process with steps labeled "call Jim in accounting".