Avoid a Healthcare.gov Flop: Listen to Your Developers

Whether it’s customers or political capital, a poor user experience can cost you. Need proof? May we direct your attention to Healthcare.gov – the site went live Oct. 1 and, to the frustration of users, hasn’t really worked since.

Now, developers who worked on the site are publicly lamenting unrealistic deadlines, last-minute requests for changes and ignored warnings of bugs. The result? Up to 5 million lines of code need to be rewritten before Healthcare.gov does what it is supposed to do, according to a New York Times source.

Learn from the mistakes of Healthcare.gov. Here are three things non-technical stakeholders need to know about developing software.

Know the Process

Say you’re standing on top of a hill, looking across a valley to another hilltop. From that vantage point, getting from one hilltop to the other seems easy enough – just a straight shot across. But once you make your way down into the valley, you may discover creeks that need to be forded and thick brush that needs to be circumvented. Getting from one hill to the other becomes tougher than anticipated.

And so it goes with developing a complex website: “No matter how good the engineer or how explicit the design requirements, an element of guess work will always be there,” says Michael Dreyer, a software engineer for CareerBliss.

Any number of things can crop up and delay progress – a problem with some code, a downed server, a broken system.

“It’s not the stuff we don’t know that worries me,” says CyberCoders software engineer Tad Kaput. “It’s the stuff we don’t know that we don’t know.”

Expectations are likely to be more realistic if non-technical stakeholders are familiar with the process, and pitfalls, of software development.

Listen to Your Developers

From the AP: [Healthcare.gov] project developers … said they raised doubts among themselves whether the website could be ready in time. They complained openly to each other about what they considered tight and unrealistic deadlines. One was nearly brought to tears over the stress of finishing on time, one developer said. Website builders saw red flags for months.

Software developers, in general, want to build great things that are useful to a lot of people. Trust them to do that. If your developers are telling you there are big problems, it’s best to listen, inquire about solutions and adjust accordingly.

“It’s not just about slinging code, but producing something that has a measurable and positive impact, helps others and solves interesting problems,” Geoff Hudik, senior software engineer at CyberCoders says.

Don’t let a Deadline Kill the Product

Deadlines can be helpful in guiding the progress of a project – as long as they anticipate unforeseen circumstances.

“Managers want their product ASAP,” says Dreyer, “but often don’t have the technical awareness of the many things that can happen during development that will delay the project delivery date.”

Standing firm on a deadline, despite reasonable concerns from the development team, can result in a Pyrrhic victory: The project is completed on time, but end product doesn’t do what it is supposed to. In the case of Healthcare.gov, missing the deadline would have been a minor embarrassment compared the ongoing humiliation of launching a $400 million site that, for most people, doesn’t work.

“Like everything else in this world it’s all about balance,” Dreyer says. “Managers need to give engineers the freedom to do what they do best: produce quality code. At the same time, engineers need to be aware of the responsibilities managers have.”