Major problems with the new ACA website healthcare.gov are being reported and criticized throughout the media. It’s a great story, definitely worth reporting and much easier to write about than the complexities of the new law and how it will affect millions of people.
Fortunately, states that chose to create their own websites, like California and New York, are doing better, one likely reason being that their software requirements were easier to implement. It’s states with Republican governors or legislatures that didn’t create their own websites, like Texas, Florida and New Jersey, that are especially suffering. Although there are other ways to sign up for ACA-generated health insurance (by phone, and even in person), it’s still a problem for many people who live in those Republican-governed states.
Still, it’s an especially poignant example of how Republicans often put politics above principle or pragmatism. One would think that politicians who consistently criticize the Federal government (except for the Defense Department, etc.) wouldn’t depend on a Federal website delivering health insurance to their citizens, but go figure.
It’s also a great example of how large computer projects usually fail to meet deadlines, and how corporations that sell things to the government almost always find a way to make a whole lot of money. “We will deliver X by Y for $Z” repeatedly turns into “we will deliver X- by Y+ for $Z++”. Everyone involved usually has an excuse – it’s often the fault of those other guys – but whatever happens always results from a team effort.
For more on the software development aspect of the situation, here’s an honest, accurate appraisal from someone who has clearly been in similar situations:
In fact, we software developers suck at estimating how long it will take to build a web application (it’s time that we admit that). So, if we suck at it, imagine how poorly our managers who have never written a line of code suck at it when they pull estimates out of their asses to impose on their development teams and report to their bosses.
The whole article is worth reading, although I’ll add that these problems aren’t limited to web applications, many people who give optimistic estimates have done plenty of coding, and the people doing the requirements aren’t always the most blameworthy. Software developers frequently slow down the requirements-writing process by failing to give feedback, asking for repeated clarifications, arguing about which features are necessary and failing to move forward when progress could be made. In addition, there may be good reasons to roll out software that isn’t ready (sometimes, something is better than nothing). It really is a team effort.
Whereof One Can Speak 🇺🇦 
You must be logged in to post a comment.