There are so many moving pieces, and while I understand that, $293M for one piece. Half a billion for a website.
Christ.
Or is google just a website? Is yahoo.com just a website? Did you look at the infograph?
How much do you think it will take to talk to 5 agencies and 300 insurance providers that have 4500+ health plans, and get them to agree/adhere, understand their EXISTING system and build a site?
I'm not justifying the expense, but let's not trivialize the task at hand and call it just a website.
CGI Federal literally ripped off the government, screwed the American people badly, and "stole" hundreds of millions. They should never be allowed to work on another project again and should be required to refund the government. The project managers should be fired and publicly humiliated.
I STILL cannot even login to the website. The site has said "The system is down at the moment." for the past two weeks.
The only reasonable explanation that I can imagine is sabotage by someone who didn't want Obamacare to succeed, the same thing that happened in Congress recently.
It depends how you define "success". While most people assume success as a well-oiled healthcare machine that is affordable and cares about you then yes, they have failed. However, if you have done your homework on Obama and Democratic party (in biggest part), you will understand that they already greatly succeed - that is they shoved a huge tax (that over 10 years grow to 10% of your income, starting with 1% next year) in american's throat. While congress pass the law and Supreme Court upheld it, rest is just a statistic noise. Who care congress has 11% approval? Who care Obama has vanishing approval rate and his administration cannot catch up with any "phoney" scandals they getting into every month it seems? Its all irrelevant. After all, they did not hire 16,000 new physicians; they hired 16,000 new IRS workers that will be responsible for collecting what you lawfully owe. That's all! Its all about the taxes; its never been about you or your health. The only way Obama ACA would be more successful is that every single american throw a towel and say "screw it, I will pay the fine, this is too complicated!". That would be the best scenario for the Obama and the gov.
> the same thing that happened in Congress recently.
I think you mean the shutdown. It was so pathethic that it is funny. Imagine situation when you drive to work every day. And then every weekend you go out and drink and drive. The cop pulled you over twice but he let you go with a warning. You keep drinking and driving. Then one day he pulled you over, boom! DUI, license revoked. Then you go to your friends and family and you complain that because of this cop now you cannot do your work, because you drove to the office every day. If you agree with this reasoning then yes Reps were responsible for shutting down the Gov and not letting Congress do their work.
http://www.washingtonpost.com/blogs/fact-checker/wp/2013/10/...
Put that in your head...
However, I do agree that the costs for this are extravagant and there are certainly signs of "government milking" visible here.
While it's easy for people to crap on things like js-minifying, cache control, etc - the hard reality is the stuff that is the hardest is so hard that most people have never done anything even remotely close.
Having worked on 10m+ loc codebases, life gets very hard. Dynamic languages tend to be unworkable. Module control, strong interfaces, and a lot of division of responsibility becomes the order of the day. And just figuring out how to build the thing becomes it's own team.
For those who are just thinking "so, just slap together some JSON/web services and call it a day" - I invite you to research EDI and then report back here. Assuming you're still alive.
Which EDI standar ... ohhh I see what you're getting at.
When you look at it like a single point aggregating all this information from all these separate insurance companies, it's amazing it works at all.
When you look at the website failing the way it is though, you can't help but ask 'did they even test this thing' even when you know better.
When you look at it from a user point of view, it's too bad it appears to not work at all.
With EDI you don't get to dictate standards, you can't demand JSON/web interfaces, you usually have to deal with flat text files (good luck) or schemaless XML (you're doomed) if that. Some vendors just provide XLS files to an FTP endpoint and call it a day. Some vendors send pricing information exclusively in PDF format over email. The manufacturers never maintain a format for more than a month, and downstream consumers of data can never decide how they want it.
Finally, you'd think that once you get all of that mess sorted out you're golden. The only problem is that the auto industry is the land that time and UPC codes forgot, and there are multiple inconsistent standards for labeling parts, and data services that claim to have a mapping between them are selling snake oil at prices several orders of magnitude higher than what you'd think fair.
Also no one in this industry believes in using software developed in the last ten years and I think I'll be near retirement age before my successors will first receive vendor data in JSON over HTTP/1.0.
"One obvious reason is that they're serving unminified and unconcatenated Javascript and CSS files. A single page load causes 92 requests to the server, and they're not using a CDN for any of that.
They're also not setting the Cache-Control and Expires headers, so the browser isn't caching many of those files, including on 80k file full of response strings.
For the non-technical, this means the site is essentially killing itself. An optimized and properly tuned production website would load one (1) HTML document, one (1) CSS document, and one (1!) JS document, they're loading 92. "
Things may have changed since October 1st, but on second page load of the home-page, I'm seeing the majority of content as either cached or served by CDN, a relatively small functional payload compared to a lot of HN darlings, and an 79ms latency for the main request.
None of that is really alarming IMO.
Even so, half these assets are trackers and 3rd party resources that would probably be CDNed externally. If storage IO and bandwidth isn't your limit (and internally the URLs could easily be routed to different servers entirely as well as caching proxies), then it's pretty plausible that there's practically nil overall performance impact as far as service availability goes.
Also, I think the whole "you should only use one of each type of asset" philosophy is debatable at least.
I am a supporter of open and non-MS software but I don't think we can blame it on the technology this time.
In my experience so far a well engineered system, will perform regardless of the technology stack picked. Picking technology X or Y will not compensate for bad architecture and engineering practices.
I always had this non founded impression that something running on the JVM would be slow ... this author also. Anyone with data to back this impression ?
That said, my experiences with JBoss haven't left me enamoured of it, and it certainly wouldn't be my first choice.
There are a ton of Java frameworks in the top performing benchmarks (See Lng:Jav). Whatever conclusion you've made from Java Swing applications running on top of WindowsXP machines in the early 00's are not applicable to modern web server performance.
No. Because it's not the AS that is slow. Someone else's code that is not efficient enough or doing too much DB calls.
Edit: Working non stop for 30 years.
- Software licenses
- Software support/contracts (Redhat -> JBoss AS)
- Hardware
- Office space
- Benefits
- Infrastructure contracts (for 10 years... or 100 years)
I'm not suggesting that the government create a meta-marketplace for health insurance marketplaces. Just that it isn't as efficient as some people think to introduce a powerful federal competitor with 'unfair advantages' like public funding into the health insurance selection market.
The number of different 3rd party libraries that are required, the type incompatibilities, matching fields, accounting for changes in the schema, and talking to legacy systems (I am sure there are many of them in there...), all in 5 months? Good luck.
Add to this the overhead of talking to IT and management of insurance companies, the IRS and others, and just the fact that it does answer some queries is fairly impressive in my book.
Also I am sure that most of those systems are failry deep inside the corporate networks of these insurers, just getting access to them probably was not an easy task.
That said the authentication layers failures and lack of testing are far from impressive.
Is that what CMS does?
