Could A Tech Giant Build A Better Health Exchange? Maybe Not

I can see the headlines and complaints now. People will complain that you're forgetting about $EDGE_CASE, like pensioners who worked abroa/new unmarried mothers/mothers who divorced recently/young children with $RARE_DISABILITY/etc./etc.

No matter what you do, so photographic sympathy story will have been "delibrately left behind". No politican wants to sign off on that.

You can't win.

It isn't about the tech at all, it is about getting the contracts. To pick those 15 companies, you would still need a proposal system, a validation system, an auditing system. Because the scope would be small and doable, and 15 independent contracts going out -- tens of thousands would flood in with proposals. Now you created a brand new problem, now you can't even START the contract, because picking winners has become to onerous.

The reason government gets so bogged down is an attempt at fairness and legal constraints in how they work -- the problems are actually really complex, even for stuff that seems simple on the surface.

Generally, it seems stupidity of an organization scales with the number of people therein, private or not. Even corporations let horrible products persist if they don't hear enough whining. Government just has some extra features that make it bad at projects like this.

The project managers are total PMP dopes that know fuck all about software engineering. People get promoted to those positions because they are political. Not because they know what they are doing. Back in my big corp life from 5-6 years ago, I witnessed several multi-million dollar train wrecks. They were the epitome of sunk costs fallacies.

Oracle and IBM both have great developers working on products that are core technology that both those companies sell, but their software engineering consulting and project management is atrocious. There is a reason why companies like Thoughtworks exist. TW and similar firms come in to clean up the messes started by the Oracles and IBMs of the world.

First, you can forget about having documentation of any kind or anything as recent as XML.

Also...

8) Nearly everyone you need to interface with on the customer side is apathetic at best. More likely, they are plain adversarial for fear that the work you're doing will eliminate their jobs. A single person can plop themselves in your critical path and refuse to cooperate - millions of dollars or public safety be dammed - there is nothing you can do other than work around them.

9) You will need to coordinate with half a dozen other subs under the contract prime. Some of those subs will be unassailable due to pre-existing relationships. Others will depend on talent with a 10 hour time difference. One will suddenly be in charge of "testing" your code in order to generate more billable hours. You will be in a constant battle to avoid being used and abused by the prime to make up for the deficiencies of other subs.

My first job out of college involved connecting to various pieces of hospital equipment. The equipment connected to our gateway (the project I was assigned to work on) via RS-232 cables, communicating using a standard protocol known as HL7.

Standard cables, standard protocol -- what could possibly go wrong? The answer: Everything. Everyone interpreted RS-232 in whatever they wanted. Everyone ignored the parts of HL7 they disliked, and added things that were "obviously" important. Getting decent documentation was nearly impossible.

The bottom line is that software development is relatively easy when you're in a vacuum. The moment that you need to integrate with someone else's system, things get complex and difficult. And when you have to deal with several vendors, each of which has implemented a superset of a subset of the standard, things get even crazier.

When I was editing the student newspaper in college, our editing/layout computer system stopped talking to our typesetting system. The vendors blamed each other for failing to do the right thing. We had technicians come in from both companies, and they basically yelled at each other, saying that he was not implementing the standards correctly.

So yes, the Obamacare Web site will go down in software history as a cautionary tale. But if they still haven't gotten the back end to communicate with the individual insurance vendors, then I fear that the debugging process is far from complete. And claiming that interoperability is a Small Matter of Programming is easy to say when you haven't actually needed to do it.

I once worked for a company that was all "cutting edge". We built Digital Video On-Demand systems for airlines, hotels. Python, REST, JSON, media streaming. Gorgeous things. We were invited to respond to a RFP for the transit system of the city I lived in, for platform displays. Bear in mind, these systems had been in place since the seventies, and consisted of two CRTs side by side, and you could watch the image drawing line by line down the two screens like a GIF downloading over a 300bps modem (it would take up to 15 seconds to draw a screen).

Alas, this would have been so much nicer.

We prototyped a HD flatscreen system, all sorts of niceties, news, temperature, more detailed train, trip, other information... then we had to integrate things.

We -eventually- dug up a line printed (literally on that blue and white tractor dot matrix printer paper) "spec" for the message format for the PDP system hooked into their network.

Prior to that we were pulling and reverse engineering a raw serial on the wire binary protocol with messages. Oh, did I mention there was a primitive packet system written for this that would preface messages with a destination, so they could be multiplexed - i.e. you could get "Train Destination (for train 1), first stop, second stop", then "fifth stop (for train 2 on a completely different display, to be ignored)" and then back to your messages.

When was this? 2007.