Hacker News Reader

Comment by tibbon | Hacker News Reader

I'm honestly not sure why a better health exchange couldn't be built by practically any 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 seem 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.

View on HN

Man I hate it when HN makes me feel like a grizzled veteran of the technology industry, since I'm barely 30, but I suppose having ever worked with a legacy system qualifies me to comment here:

Some challenges with "Just use REST/JSON and then Bob's your uncle:"

1) You will probably not have the source code of the system you are integrating with, which is likely a mainframe system written in COBOL.

2) The engineers who built that system are retired or dead.

3) The company which they worked for is no longer operating / was sold 15 years ago to IBM and then reverse merged into a different unit 7 years ago / lost all of its records in a fire / etc.

4) Your sole documentation is the dogeared paper copy describing file formats for their sole input method, CSV files, which was current as of its publication date, before you were born.

5) Your sole documentation incorporates by reference four other documents which, ahem, yeah.

6) You have a working test suite which accurately models the production system in all respects. It is the production system. Please do not run the equivalent of Accounts.all.delete when cleaning up from your test runs. (The system won't stop you from trying to do that. No, really.)

7) Praise God, there is actually a bridge between the mainframe system and the Internet, so at least you don't have to reverse engineer wire protocols. It was coded in 1996 by IBM's crack team of integration engineers. This will give you an excellent opportunity to brush up on your Java 3.4.1. It speaks REST/JSON, as long as as you spell REST/JSON "XML". Good news, though: your time spent learning the CSV file format won't be wasted, since the XML is just a straight mapping to it. Except for the four bugs in the mapping, which are dutifully recorded in a database in Hyderabad whose existence will be exposed to you 8 months into the project.

Welcome to legacy integration! We hope you enjoy your stay.

Anecdotally, what's described here would actually be unrealistically optimistic given the context of Government where I have entirely too much experience.

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.

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.

Precisely!

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.

> Have these people never heard of REST or JSON?

I think the difficulty is really in schema matching/mapping.

Right. The systems healthcare.gov has to interface with are established and NOT subject to change. It is up to the new system to be interoperable with whats already there. And this is where this get hard: you have to be able to speak with a myriad of different systems, translate the data to and from the schema of each target system, and do it all securely and robustly. This is all much more complicated than most of the armchair critics realize.

It sounds, to me, like they should have created a centralised spec for talking to these external system. Then created teams to build the interfaces between that spec, and the external systems.

So for healthcare.gov to talk to Hospital Insurance Inc. it would actually talk to the Health Insurance Inc shim and THAT would talk to the third party.

Now you have a small(er) definable project that a team can deliver and that can be tested. 100 shims later and healthcare.gov can talk to anything because they all (appear to) use the same interface.

This may be the most hubristic comment I've ever read. No, you could not "make Postgres do what is needed for this within a week or two" just because you've heard of REST and JSON.

They probably heard of it, but they are probably using SOAP webservices or Java EE MQs

Or whatever came 10 years before that. FTP? Batch tape?

AS400 and undocumented fixed column ASCII files, probably. Been there, done that. It's not funny

Reply on news.ycombinator.com