Technology
12:06 am
Thu October 17, 2013

If A Tech Company Had Built The Federal Health Care Website

Originally published on Mon October 21, 2013 2:25 pm

HealthCare.gov was meant to create a simple, easy way for millions of Americans to shop for subsidized health care.

Instead, in a little two more than weeks, it has become the poster child for the federal government's technical ineptitude.

A dysfunctional contracting system clearly bears some of the blame. But entrepreneurs in Silicon Valley likely would have approached the project differently from the start.

A week after the site launched, NPR spoke to Suzanne Cloud, a jazz musician based in Philadelphia. At that point, Cloud had spent hours on the site, trying to sign up for coverage. "Something went wrong, and it just went to a page with all kinds of html stuff," she said.

This week, Cloud says she gave up on the website and ended up registering by phone. The folks on the phone took all of her information — then asked if she'd like to pick out her plan online or receive information about her health care options via snail mail.

Cloud chose snail mail. "Once I signed up with the telephone, I didn't go back and try the site again," she said.

At 17 days old, HealthCare.gov has become a bit of a joke — even to folks like Cloud, who were eagerly awaiting its rollout.

So how could a roughly $400 million software project that had been in the works for years have so many problems at its launch? One bit of advice from Silicon Valley: Start small.

"It's not as if Facebook says, 'OK, here is our six-year plan for how we're going to make Facebook.com,' " says entrepreneur Ben Balter. "They build one feature at a time, and take a step back, look at how the feature is be used, before they go on to the next feature."

Balter says you build something small, you test it, and when it works for your users, then you take the next step. Right now, Balter works for GitHub.

"GitHub is a social code-sharing service," he says. "Think of it like Facebook for code. So instead of posting pictures of your kids or posting ... on Twitter what you had for lunch, you are showing what projects you're working on."

By sharing the code you are writing, lots of people can critique it, find the bugs, offer ideas and make sure it works. It's called open source, and Balter believes HealthCare.gov should have been written that way from the start.

"Why would you make that code private?" Balter asks.

But often when things don't work in government, the impulse is to duck and cover and clamp down on information.

"I think the key reason is the way projects get funded," says Michael Cockrill, who used to work in startups and is now the chief information officer for Washington state.

He says to get a software project funded in the public sector, typically you have say exactly what it is going to do, spell how much it will cost and when you will finish.

"As a result, you end up creating this culture that is all about doing what you said you were gonna do," Cockrill says.

It's a culture that is risk-adverse and terrified of public failure. You can't learn from little failures or adjust course midstream. And instead of taking big jobs, breaking them down into small tasks and testing for success at each step, a project like HealthCare.gov becomes a giant all-or-nothing gamble.

Cockrill says too often it's a gamble taxpayers loose.

"You've made all these commitments about what you are going to build. What is it going to look like upfront," Cockrill says. "And even if the market changes underneath you, and even if your customers need something different — which you know always happens — you made a commitment a big public commitment, and they've written it into budgets and law."

Cockrill and many others around the country are trying to help governments become more flexible and agile as they embark on software development projects.

"It's really hard to convince people to kind of trust you," he says. "Especially when you are saying, 'Look I don't know exactly what is going to look like — but we are going to do what matters most first.' "

Copyright 2013 NPR. To see more, visit http://www.npr.org/.

Transcript

RENEE MONTAGNE, HOST:

If Congress had not shut down the federal government and tip-toed to the brink of a federal default, we might have had a different top story to report. That story could have been the disastrous rollout of Healthcare.gov, the website of the Affordable Care Act. The site was meant to create a simple, easy way for millions of Americans to shop for subsidized health care. Instead, in just over two weeks, has become the poster child for the technical ineptitude of the federal government.

NPR's Steve Henn reports.

STEVE HENN, BYLINE: One week after Healthcare.gov launched, we reached out to Suzanne Cloud, a jazz musician based in Philadelphia. At that point, she had spent hours on the site, trying to sign up for coverage.

SUZANNE CLOUD: It kind of went zzipt, and something went wrong. And it went to a page with all kinds of HTML stuff.

HENN: This week, I called Cloud back.

CLOUD: Well, I gave up, and I ended up calling in and registering that way.

HENN: The folks on the phone took all of her information, then asked if she'd like to pick out her plan online or receive information about her health care options via snail mail.

CLOUD: And I said snail mail, since I was having problems with the site. Once I signed up with the telephone, I didn't go back and try the site again. Maybe I should.

(LAUGHTER)

HENN: Seventeen days old, and Healthcare.gov has become a bit of a joke, even to folks like Cloud who were eagerly awaiting its rollout. So how could a roughly $400 million software project that's been in the works for years have so many problems at its launch? A dysfunctional contracting system clearly bears some of the blame. But I was curious: If entrepreneurs here in Silicon Valley had set out to build Healthcare.gov, what would they have done differently?

One answer is they probably would have started small.

BEN BALTER: It's not as if Facebook says, OK, here is our six-year plan for how we're going to make Facebook.com.

HENN: Ben Balter.

BALTER: They build one feature at a time and take a step back, look at how the feature is being used before they go on to the next feature.

HENN: Balter says you build something small, then you test it. And when it works for your users, you take the next step. Right now, Balter works for GitHub.

BALTER: GitHub is a social code-sharing service. It's - think of it kind of like Facebook for code. So instead of posting pictures of your kids or posting on - like you would on Twitter, what you're having for lunch, you're showing what projects you're working on.

HENN: By sharing the code you are writing, lots of people can critique it, find the bugs, offer ideas and make sure it works. It's called open source, and Balter believes Healthcare.gov should have been written that way from the start.

BALTER: Why would you make that code private?

HENN: But often, when things don't work in government, the impulse is to duck and cover and clamp down on information.

MICHAEL COCKRILL: And I think the key reason is the way projects get funded.

HENN: Michael Cockrill used to work in start ups, and is now the chief information officer in Washington state. He says to get a software project funded in the public sector, typically, you have to say exactly what it is going to do: spell how much it will cost, and then say exactly when you'll finish.

COCKRILL: And as a result, you end you creating this culture that is all about doing what you said you were going to do.

HENN: You can't learn from little failures or adjust course midstream. And instead of taking big jobs, breaking them down into small tasks and testing for success, a project like Healhtcare.gov can become a giant, all-or-nothing gamble. And Mike Cockrill says, too often, that's a gamble taxpayers loose.

MONTAGNE: Steve Henn, NPR News, Silicon Valley. Transcript provided by NPR, Copyright NPR.