I really want to. I think the Administration gets a lot of unmerited flak, but the reporting shows that this really was a blunder.
I think going forward management/focus on the exchanges will be better, but there's a question of whether the technical issues, from integrating legacy systems to making sure the info passed on to insurers is accurate, can be fixed on a limited timetable just by working harder.
I guess my answer is not really, but I hope I'm wrong.
1. No website or computer product has a 0% error rate. Even top-shelf products have "known issues" that will cause failure for some non-trivial percentage of users. (See, e.g., http://support.apple.com/kb/TS5296?viewlocale=en_US&locale=en_US.) So the inevitable "person X still got an error" human interest story will be deeply dishonest; the goal here should be to get failure rates within accepted tolerances for a comparable site - not to get them to zero.
2. Healthcare.gov necessarily works by integrating with other enterprise systems, many of which aren't partially or at all within the Administration's control. There are always work-arounds and brute-force ways of integrating, but to the extent these integration points have been the problem, there's just a limit on the extent the Administration can directly control them.
3. Every indication I've seen is that many of HC.gov's problems are architectural. In my experience, solving problems like that can be what's sometimes called a "0.9 to the fifth" problem - each individual issue may have a 0.9 chance of being solved successfully, but those probabilities all multiply on each other until the overall probability of success is much lower. Put more simply: Once you start digging on a problem like this, you never know what you're gonna find. So I believe that based on what they know today, a November fix is warranted. But I also think it's possible they could learn information that invalidates that estimate, and they could learn it at any time.
So overall: Yes, I believe that based on current information, the Administration honestly believes it can have the parts of HC.gov that it controls directly working within expected tolerances by the end of November.
Anonymous Bureaucrat, you seem to understand these things, so let me ask a question. I keep hearing lately that the HealthCare.gov website is based on out-of-date technology instead of state-of-the-art cloud technology. Casual observation tells me that when people latch on to a notion like this, they automatically attribute the decision to stupidity or laziness or some such and almost never bother to ask whether there might be a reason for doing it the way they did. So, tell me, could there be a reason for doing it the way they did? Could it be explained, for instance, by the need to integrate it with other, existing computer systems--perhaps including systems that haven't received appropriations for updates in years?
Well, first off, MyName below has it right. HC.gov was based on cloud technology - which, ironically, was the source of one of its first big unplanned outages: http://www.datacenterknowledge.com/archives/2013/10/27/terremark-data-center-outage-knocks-healthcare-gov-offline/. (Someone once joked that "the cloud" is the name for a giant data center in Northern Virginia. Funny, but also pretty much true.)
Overall, I think you're on the right track to think that systematic constraints, rather than anyone being dumb, had anything to do with it. If you combine the kind of political constraints mentioned in today's WaPo article (http://www.washingtonpost.com/politics/challenges-have-dogged-obamas-health-plan-since-2010/2013/11/02/453fba42-426b-11e3-a624-41d661b0bb78_story.html) with the procurement-oriented constraints that Clay Johnson and others have written about, I think you have something much closer to the root cause.
I also wouldn't ignore the importance of Kevin Drum's small-but-important point about schedule slippage here: http://www.motherjones.com/kevin-drum/2013/10/just-how-bad-obamacare-website-anyway. The closest thing there is to a Professional Web Developer Mantra is: "Cheap, Fast, Good - Pick Two." Cost, scope, and schedule are an iron triangle. The law itself pretty much fixes schedule and scope, and political and realistic considerations meant there wasn't much cost flexibility. So when none of the three legs of the stool can change, you get...well, you get what we got.
I think you're also right that there's a legacy software issue at play here, but not quite the way you think. The frontend of HC.gov was built by a snappy little startup in DC (http://www.washingtonpost.com/blogs/wonkblog/wp/2013/10/09/healthcare-gov-was-originally-built-in-a-garage/), and as far as I can tell, it's been working in a not-optimized-but-basically-totally-fine way. The backend is the hard part, though: It's the part that has to handle user information, store, retrieve and serve it efficiently, and interface with health companies. That's not impossible, but it's really hard when you don't really have any *direct* control over the legacy systems you have to interface with.
Bottom line: The idea that the site being "based on out-of-date technology" is the *cause* of what we've seen so far is just dumb. Plenty of state, local, and federal government sites running today are based on what I'd consider out-of-date technology, and while many are too expensive or not pretty, _they run just fine_. (See, e.g., every state DMV site.) There are a lot of interrelated reasons for what we've seen so far from HC.gov. Some were structural, some are basically human error, and some are the fruits of many years of previously-made bad decisions.
By the way, just to be clear: While I am indeed a civil servant (as my handle implies), I am in no way part of or even remotely connected to anything having to do with HC.gov or any of the entities responsible for it. You're not getting any kind of "inside scoop" here - just a mildly well-informed take on what I read in the papers.
It's not stupidity or laziness. Putting something "in the cloud" isn't really a separate technology. It is a group of techniques of organizing the data that makes up your website so that it can be easily split up and/or duplicated. This allows you to just throw more hardware at traffic problems and also avoid single points of failure in the hardware you're using.
This technique runs into problems when you're trying to use it to handle large amounts of data, that needs to be secure, and may be on a legacy system. Which describes healthcare.gov
Not quite. Zients said "by the end of November, HealthCare.gov will work smoothly for the vast majority of users." I think it will work effectively but not smoothly for most users, and not smoothly enough for many of the target users. Even so I think the website will work well enough to advance the program.
Zients would be a complete idiot to make such a specific promise if he didn't have very high confidence in it, presumably based on some kind of close assessment of what was needed. That said, he also talks about things like a "punch list." A punch list? You mean, priorities? If he turns out to be wrong, I can tell you who's going to be at the top of MY punch list.
Two remarks: 1) I'm a gamer, and EA/DICE released Battlefield 4 this past week, and it has massive problems with frequent client and server crashes, and a whole slew of nasty bugs. They have released at least 5 patches, and it is still severely broken. I don't excuse EA/DICE or Healthcare.gov, but it's instructive that even the private sector fails with software, even when they have plenty of resources and there's an actual profit motive in play.
As to whether the end of Nov. is a realistic goal for 99%/aka fully functional, it's really hard to say without knowing more about the systems involved. If it's purely the Healthcare.gov backend, then yes, but if it involves fixing various insurance company systems, then who really knows, it could take a year.
2) Upon watching "The Falcon and the Snowman" this weekend, I looked up the Australian Prime Minister in question, http://en.wikipedia.org/wiki/Gough_Whitlam, and found it eerily like our current political battles (Whitlam introduced universal healthcare, was hampered by failure of 'supply' (aka government funding), and various election issues insued, which ultimately lead to him being dismissed by the Governor-General. I wonder if you're familiar with this story?
It's too bad they set such a date as frankly it doesn't matter as long as the move back the date that all have to have insurance. The important thing is make it work. Do I believe them? As much as then they said you can keep your insurance (if you like it) without qualifying that meant your 'real' insurance. What people paid premiums for wasn't necessarily ever insurance. Obama left out a word.
It would look very bad if they couldn't set a date. Let's hope that they set a date based on educated guesses on how long it would take, not based on political expediency. I hope they can meet that deadline.
Also, pushing back the starting date of the insurance plans messes with the insurance companies' plans and the prices that they gave for insurance policies. Pushing back the date, or delaying the individual mandate for a year, runs the risk of invalidating the promises made to date regarding the policies on offer.
Yeah, I think so. I guess JB is still trapped in nightmare/limbo what have you based on his tweets about this, but honestly I feel like the fact that "website woes" stories have really died down in the last few weeks is pretty good evidence that the whole thing has actually improved.
The again I signed up for everything via a state exchange (Minnesota) so that makes me pretty optimistic.
Anecdotally, and FWIW, I successfully enrolled last Friday. I stopped short of choosing an actual plan because I didn't have time to verify which of the plans my current doctor takes. So maybe I'm only half way through but it is farther than others I know got when they tried to sign up on 10/01.
I really want to. I think the Administration gets a lot of unmerited flak, but the reporting shows that this really was a blunder.
ReplyDeleteI think going forward management/focus on the exchanges will be better, but there's a question of whether the technical issues, from integrating legacy systems to making sure the info passed on to insurers is accurate, can be fixed on a limited timetable just by working harder.
I guess my answer is not really, but I hope I'm wrong.
Yes, with three caveats:
ReplyDelete1. No website or computer product has a 0% error rate. Even top-shelf products have "known issues" that will cause failure for some non-trivial percentage of users. (See, e.g., http://support.apple.com/kb/TS5296?viewlocale=en_US&locale=en_US.) So the inevitable "person X still got an error" human interest story will be deeply dishonest; the goal here should be to get failure rates within accepted tolerances for a comparable site - not to get them to zero.
2. Healthcare.gov necessarily works by integrating with other enterprise systems, many of which aren't partially or at all within the Administration's control. There are always work-arounds and brute-force ways of integrating, but to the extent these integration points have been the problem, there's just a limit on the extent the Administration can directly control them.
3. Every indication I've seen is that many of HC.gov's problems are architectural. In my experience, solving problems like that can be what's sometimes called a "0.9 to the fifth" problem - each individual issue may have a 0.9 chance of being solved successfully, but those probabilities all multiply on each other until the overall probability of success is much lower. Put more simply: Once you start digging on a problem like this, you never know what you're gonna find. So I believe that based on what they know today, a November fix is warranted. But I also think it's possible they could learn information that invalidates that estimate, and they could learn it at any time.
So overall: Yes, I believe that based on current information, the Administration honestly believes it can have the parts of HC.gov that it controls directly working within expected tolerances by the end of November.
- Anonymous Bureaucrat
Anonymous Bureaucrat, you seem to understand these things, so let me ask a question. I keep hearing lately that the HealthCare.gov website is based on out-of-date technology instead of state-of-the-art cloud technology. Casual observation tells me that when people latch on to a notion like this, they automatically attribute the decision to stupidity or laziness or some such and almost never bother to ask whether there might be a reason for doing it the way they did. So, tell me, could there be a reason for doing it the way they did? Could it be explained, for instance, by the need to integrate it with other, existing computer systems--perhaps including systems that haven't received appropriations for updates in years?
DeleteWell, first off, MyName below has it right. HC.gov was based on cloud technology - which, ironically, was the source of one of its first big unplanned outages: http://www.datacenterknowledge.com/archives/2013/10/27/terremark-data-center-outage-knocks-healthcare-gov-offline/. (Someone once joked that "the cloud" is the name for a giant data center in Northern Virginia. Funny, but also pretty much true.)
DeleteOverall, I think you're on the right track to think that systematic constraints, rather than anyone being dumb, had anything to do with it. If you combine the kind of political constraints mentioned in today's WaPo article (http://www.washingtonpost.com/politics/challenges-have-dogged-obamas-health-plan-since-2010/2013/11/02/453fba42-426b-11e3-a624-41d661b0bb78_story.html) with the procurement-oriented constraints that Clay Johnson and others have written about, I think you have something much closer to the root cause.
I also wouldn't ignore the importance of Kevin Drum's small-but-important point about schedule slippage here: http://www.motherjones.com/kevin-drum/2013/10/just-how-bad-obamacare-website-anyway. The closest thing there is to a Professional Web Developer Mantra is: "Cheap, Fast, Good - Pick Two." Cost, scope, and schedule are an iron triangle. The law itself pretty much fixes schedule and scope, and political and realistic considerations meant there wasn't much cost flexibility. So when none of the three legs of the stool can change, you get...well, you get what we got.
I think you're also right that there's a legacy software issue at play here, but not quite the way you think. The frontend of HC.gov was built by a snappy little startup in DC (http://www.washingtonpost.com/blogs/wonkblog/wp/2013/10/09/healthcare-gov-was-originally-built-in-a-garage/), and as far as I can tell, it's been working in a not-optimized-but-basically-totally-fine way. The backend is the hard part, though: It's the part that has to handle user information, store, retrieve and serve it efficiently, and interface with health companies. That's not impossible, but it's really hard when you don't really have any *direct* control over the legacy systems you have to interface with.
Bottom line: The idea that the site being "based on out-of-date technology" is the *cause* of what we've seen so far is just dumb. Plenty of state, local, and federal government sites running today are based on what I'd consider out-of-date technology, and while many are too expensive or not pretty, _they run just fine_. (See, e.g., every state DMV site.) There are a lot of interrelated reasons for what we've seen so far from HC.gov. Some were structural, some are basically human error, and some are the fruits of many years of previously-made bad decisions.
- AB
By the way, just to be clear: While I am indeed a civil servant (as my handle implies), I am in no way part of or even remotely connected to anything having to do with HC.gov or any of the entities responsible for it. You're not getting any kind of "inside scoop" here - just a mildly well-informed take on what I read in the papers.
DeleteThank you, AB, and MyName, too. That was helpful.
DeleteIt's not stupidity or laziness. Putting something "in the cloud" isn't really a separate technology. It is a group of techniques of organizing the data that makes up your website so that it can be easily split up and/or duplicated. This allows you to just throw more hardware at traffic problems and also avoid single points of failure in the hardware you're using.
ReplyDeleteThis technique runs into problems when you're trying to use it to handle large amounts of data, that needs to be secure, and may be on a legacy system. Which describes healthcare.gov
Not quite. Zients said "by the end of November, HealthCare.gov will work smoothly for the vast majority of users." I think it will work effectively but not smoothly for most users, and not smoothly enough for many of the target users. Even so I think the website will work well enough to advance the program.
ReplyDeleteZients would be a complete idiot to make such a specific promise if he didn't have very high confidence in it, presumably based on some kind of close assessment of what was needed. That said, he also talks about things like a "punch list." A punch list? You mean, priorities? If he turns out to be wrong, I can tell you who's going to be at the top of MY punch list.
ReplyDeleteYo, AB! Now we love you.
ReplyDeleteHi! And, uh, thanks.
Delete- AB
Two remarks:
ReplyDelete1) I'm a gamer, and EA/DICE released Battlefield 4 this past week, and it has massive problems with frequent client and server crashes, and a whole slew of nasty bugs. They have released at least 5 patches, and it is still severely broken. I don't excuse EA/DICE or Healthcare.gov, but it's instructive that even the private sector fails with software, even when they have plenty of resources and there's an actual profit motive in play.
As to whether the end of Nov. is a realistic goal for 99%/aka fully functional, it's really hard to say without knowing more about the systems involved. If it's purely the Healthcare.gov backend, then yes, but if it involves fixing various insurance company systems, then who really knows, it could take a year.
2) Upon watching "The Falcon and the Snowman" this weekend, I looked up the Australian Prime Minister in question, http://en.wikipedia.org/wiki/Gough_Whitlam, and found it eerily like our current political battles (Whitlam introduced universal healthcare, was hampered by failure of 'supply' (aka government funding), and various election issues insued, which ultimately lead to him being dismissed by the Governor-General. I wonder if you're familiar with this story?
It's too bad they set such a date as frankly it doesn't matter as long as the move back the date that all have to have insurance. The important thing is make it work. Do I believe them? As much as then they said you can keep your insurance (if you like it) without qualifying that meant your 'real' insurance. What people paid premiums for wasn't necessarily ever insurance. Obama left out a word.
ReplyDeleteIt would look very bad if they couldn't set a date. Let's hope that they set a date based on educated guesses on how long it would take, not based on political expediency. I hope they can meet that deadline.
DeleteAlso, pushing back the starting date of the insurance plans messes with the insurance companies' plans and the prices that they gave for insurance policies. Pushing back the date, or delaying the individual mandate for a year, runs the risk of invalidating the promises made to date regarding the policies on offer.
DeleteYeah, I think so. I guess JB is still trapped in nightmare/limbo what have you based on his tweets about this, but honestly I feel like the fact that "website woes" stories have really died down in the last few weeks is pretty good evidence that the whole thing has actually improved.
ReplyDeleteThe again I signed up for everything via a state exchange (Minnesota) so that makes me pretty optimistic.
I believe them.
ReplyDeleteAnecdotally, and FWIW, I successfully enrolled last Friday. I stopped short of choosing an actual plan because I didn't have time to verify which of the plans my current doctor takes. So maybe I'm only half way through but it is farther than others I know got when they tried to sign up on 10/01.
ReplyDelete