By Brent Parrish
Just when I think I’ve heard it all about all the bad engineering that went behind the Obamacare web site disaster, I stumble onto this: apparently the Oregon online healthcare exchanges only work with Internet Explorer.
Mara Zebest posted at Gateway Pundit:
This is rich…
The Oregon healthcare exchange has been pumping a ton of taxpayer money into Hipster ads that appeal to the hippy lib young crowd.
But so far no one has signed up for Obamacare in the state.
And now it’s discovered that their exchange website only works for Internet Explorer. So all those young people that like to use Firefox, Safari, Chrome, etc… are out of luck…
CoverOregon.org, was “built and tested for use with Internet Explorer,” and may “not work properly” if used on other browsers, according to the site.
This all just makes me shake my head. As a matter of fact, I wrote a article for the Watcher’s Council that looked at the whole healthcare.gov fiasco from a software engineer’s perspective a little over a week ago, and I discussed this very issue–the need to decouple the interface from the back-end. When I see a design flaw like this–meaning: it only works with Internet Explorer–I know I’m dealing with some amateurish design.
One of the major goals in good software design is to apply the correct design patterns in order to decouple the back-end logic from the front-end presentation for maximum flexibility in numerous implementations and instances. Once again, it’s important to abstract the back-end so that the application is not locked to just one interface.
In my article “ObamaSoft — The World’s Worst Rollout in History,” I wrote:
An illustration of this concept would be a web application that would only work if the end-user was using Microsoft Internet Explorer 9.0 (RC 1.9.8080.16413) web browser with the latest Java patch for IE [Internet Explorer]. The back-end code should be flexible enough so that it is not locked into a single interface, but rather provide a standardized application programming interface (API) that can work with multiple interfaces–such as different browsers types, mobile devices, web services and stand-alone applications. Decoupling the back-end from the interface is paramount in a distributed application that must communicate with multiple servers. Without a properly abstracted API that can provide multiple interfaces to the back-end application layer, the code required to communicate with multiple server applications becomes a maintenance nightmare, and may simply not work at all over time.
Dear software engineers, we've all seen a software facade in our careers, haven't we! Yes we have. Deadline: Nov. 30 pic.twitter.com/N3meeNjbcy
— The Right Citizen® ? (@therightplanet1) November 3, 2013
This brings me to something I have thought for a very long time now: if you want to create a software application that will never work (or government)–or only kinda, sorta at best–then give the job to a progressive liberal.
Let me back up … see, the whole notion behind universal healthcare is an utopian vision of an end-all-be-all solution to all of of your healthcare needs. The government will now provide all of your spiritual, emotional and physical needs–which the Obama regime wrongly refers to as “constitutional rights.”
What the Patient Protection and Affordable Care Act (a.k.a. Obamacare) is attempting to do is shut down the entire private insurance industry and run the entire marketplace all by its lonesome. Oh, and the Obama regime just up and decided they could whip up a web site in no time to handle running one-sixth of the nation’s economy. Software that’s based on emotional appeals–as opposed to hard, cold logic–is a sure candidate for “fail.” Software applications that attempt to be the end-all-be-all of off all software applications usually end up sucking in major-league fashion.
The concept behind the Healthcare.gov web site is not particularly complex per se, so far as design is concerned–like filling out a paper form on your computer and getting a subsidy. The Obamacare site is ostensibly a system to compare plans, estimate subsidies, then pick one and apply for the real subsidy. The problem is trying to get the whole system to interface and play nicely with all the remote government services required by the verification process.
If Healthcare.gov was just an aggregator and quote comparison site, the whole design process would be fairly straight-forward. The problem is healthcare.gov will not even allow an end-user to browse and compare plans without applying and enrolling (if you can) before you can do any “browsing.”
The enrollment process requires verification of the user’s personal information via the Federal Data Services Hub. The architecture of The Hub has many concerning design and security issues. From what I’ve read, there are over a 100+ interfaces to the Hub right now. Doubtful that these interfaces have been properly abstracted and standardized. Multiple government services must be contacted during the enrollment process for each user, thus creating a huge bottleneck, and a very insecure one at that.
I predict this whole web site fiasco will continue to be a fiasco because the whole thing was built on a false premise–socialism.
CBS Seattle reported the Oregon healthcare exchange has yet to enroll a single person:
SALEM, Ore. (AP) — With a reputation as a pacesetter in health care, Oregon laid out bold plans for complying with the federal overhaul.
The state wouldn’t just create a health insurance exchange, a complicated undertaking in its own right. Oregon officials set out to build one of the biggest and best in the nation — a model that other states would want to copy.
But more than a month after Cover Oregon’s online enrollment was supposed to launch, reality is lagging far behind Gov. John Kitzhaber’s grand ideas. The online system still doesn’t work, and the exchange has yet to enroll a single person in health insurance.