My cat, Trick, is a stray who followed my wife home. He recently had surgery and he picked at the stitches immediately after coming home. After taking him back to the vet, he had to have a cone of shame around his neck for two whole weeks.
The cone of shame was on him because he couldn’t stop picking at a healing wound. While the rest of his body was busy healing the problem, getting used to his newly fixed hip, his brain was telling him to do anything he could to get inside of that wound and see what was going on.
Developers can be like my cat. 
There are bits of software that some coders just like to continuously tinker with. Some call it optimization passes, others call it refinement. But there comes a point where some things just need to be left alone so the rest of the organism can get used to it and grow around it.
This is the prevailing attitude in legacy systems: Don’t touch that, it works. The folks who actually wrote that bit of legacy system, however, could probably think of a few things they could fix about it. In most cases, that is. There are certainly terrific examples of legacy systems that had to overcome tremendous problems, and are thus engineered down to the bit.
Then there’s BANCStar. It was so convoluted, difficult and constrained that developers would actually hook into existing values used elsewhere in the system in order to save the few bits of code and process time needed to set an integer into memory.
But I digress. The point here is that there is a careful balance of what my cat is doing right and what he is doing wrong, just as there is a balance between a developer who knows when to stop versus one who knows when to keep pushing the boundaries.
I say all of this to make a point about the HealthCare.gov website. Behind this supposed debacle of a site, there are connections to dozens, perhaps hundreds of proprietary, legacy systems written by developers who likely knew when to push boundaries, but were not allowed to.
Those legacy health insurance calculation systems probably aren’t of the “optimized down to the bit” variety. They were likely written by developers who were wearing their own management-induced cones of shame. So, imprisoned in these cones and desperate to fix all the problems inherent around the ailing cat body that was their system architecture, they could do nothing more than clean the tips of their feet and tail, unable to reach their barbed tongue of code into the festering wounds.
(A harsher take on HealthCare.gov’s coding woes: It’s enough to make you sick)
Trouble is, there’s no surgery here. My cat was fixed by a trained medical professional who knew what the cat needed better than it did. This HealthCare.gov thing is more akin to going to the vet to have a new cat put together, cobbled together from old broken bits of cat they had lying around the offices.
I do not envy the task before whoever has to manage this HealthCare.gov thing into usefulness. The actual developers working on the front end and government-side systems administration are probably top notch, and highly motivated.
It’s a shame they have to integrate into hostile systems. Let’s face it: The healthcare companies have no incentive to host their information quickly and easily. They don’t make any extra money from this system, as price competition is always bad if there isn’t any already in the marketplace. Thus, when mandated to make available their highly secret, core business insurance algorithms, why not just open a port in the firewall to the VAX in the basement in Omaha that runs all those checks?
If it was some frontline, shiny new IBM cluster, or a hot new Oracle box, that’d be a waste of resources. Those machines are better for running analytics upstairs to refine the algorithms. The actual hosting of those algorithms never needed to be fast to begin with, as applying for health insurance is a multi-step, complex process. It’s also a process where they can tell if you you’re too fat, too thin or too diabetic to receive healthcare.
Why rush that pain on the customer? The healthcare industry is used to approving, denying and offering a price after days of scrutiny, usually involving a live human being. When the government stipulated that their rates be available for a quote in just a few seconds, I doubt any enterprise-size healthcare IT team was immediately saddled with the burden of meeting those demands.
Instead, the developers who wrote HealthCare.gov were saddled with that SLA-style agreement. And they’re going to get the heat and scorn for the problems that site is facing. I feel very badly for them, sitting in their cubicles in their cones of shame. Let’s all hope there’s a doctor in the house who can fix this ailing patient.
And let’s all hope my cat stops pulling the cone off of his head.
