This is totally right. My first job out of college involved connecting to various pieces of hospital equipment. The equipment connected to our gateway (the pr

This is totally right. 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.