Whenever I hear someone say that "government should be run like a business," my first reaction is "do you know how badly most businesses are run?" Seriously. I do not want my government to run like a business — whether it's like the local restaurants that pop up and die like wildflowers, or megacorporations that sell broken products, whether financial, automotive, or otherwise.
If you read some elements of the press, it's easy to think that healthcare.gov is the first time that a website failed. And it's easy to forget that a large non-government website was failing, in surprisingly similar ways, at roughly the same time. I'm talking about the Common App site, the site high school seniors use to apply to most colleges in the US. There were problems with pasting in essays, problems with accepting payments, problems with the app mysteriously hanging for hours, and more.
I don't mean to pick on Common App; you've no doubt had your own experience with woefully bad online services: insurance companies, Internet providers, even online shopping. I've seen my doctor swear at the Epic electronic medical records application when it crashed repeatedly during an appointment. So, yes, the government builds bad software. So does private enterprise. All the time. According to TechRepublic, 68% of all software projects fail. We can debate why, and we can even debate the numbers, but there's clearly a lot of software #fail out there — in industry, in non-profits, and yes, in government.
With that in mind, it's worth looking at the U.S. CIO's Digital Services Playbook. It's not ideal, and in many respects, its flaws reveal its origins. But it's pretty good, and should certainly serve as a model, not just for the government, but for any organization, small or large, that is building an online presence.
The playbook consists of 13 principles (called "plays") that drive modern software development:
- Understand what people need
- Address the whole experience, from start to finish
- Make it simple and intuitive
- Build the service using agile and iterative practices
- Structure budgets and contracts to support delivery
- Assign one leader and hold that person accountable
- Bring in experienced teams
- Choose a modern technology stack
- Deploy in a flexible hosting environment
- Automate testing and deployments
- Manage security and privacy through reusable processes
- Use data to drive decisions
- Default to open
These aren't abstract principles: most of them should be familiar to anyone who has read about agile software development, attended one of our Velocity conferences, one of the many DevOps Days, or a similar event. All of the principles are worth reading (it's not a long document). I'm going to call out two for special attention.
First, "Understand what people need": It's all too common, both in government and in industry, to run into sites that are defined by what the site's owner needs. Whether the owner needs you to make a purchase, look at an advertisement, or sign up for insurance, the user's time on the site is defined by the owner's agenda. That's not how people work. People don't visit sites for the sake of the site: they visit the site to accomplish something. They have their own goals and agenda. That might be relatively simple (buying a book) or relatively complex (planning a trip) — but whatever the case, it's the user's agenda and convenience that counts.
The playbook stresses the importance of spending time with current and prospective users of the service. And I'm reminded of a story Gregory Brown, curator of Practicing Ruby, tells about building software for a dental practice. The receptionists hated the software they were currently using. Greg actually sat down with them to observe what they were doing and understand their job. The solution (as I remember the story) wasn't difficult: one page listed a bunch of insurance codes, and another page required the receptionist to type in the appropriate codes, but it wasn't possible to click on a code or copy and paste it within the application. You had to remember it or write it down. Easy to fix, but it's the kind of problem that I see frequently: different parts of the application were written by different people, possibly in different departments. They probably never talked to each other, let alone their users.
Don't think you're exempt from the problems that plagued healthcare.gov — you aren't.
Second, "Address the whole experience": This principle is really an extension of the first. Whether we're designing software, hardware, network-enabled devices, or something else, we need to realize that we're designing an experience. And it's the total experience that matters: not just the good parts. As Kathy Sierra says, how do you make users feel awesome? How do you make them better at what they intend to accomplish?
Together, the first two principles encapsulate the idea of empathy, which is at the core of DevOps. We shouldn't build applications to make the owner more awesome; we build them to help the user accomplish what he or she needs. That requires understanding the user's goals; communicating to understand what their pain points are; and thinking about their entire experience, from beginning to end. And realize that the user's experience isn't just the experience of the application itself. If you're building a camera, it's the experience of taking photos; if you're building healthcare.gov, it's the experience of visiting the doctor without anxiety about payment; if you're building a bookstore, it's about reading books you enjoy.
Read the entire document: it's short, it's pithy, and it's well worth it. And while you're at it, read the even shorter UK's Government Digital Service Design Principles, a somewhat older document on which the playbook was based. I hope that our government can implement the principles that are described in the playbook. A lot was learned from the failure of healthcare.gov, but learning from failure is one thing, and changing systems that have festered for years is another. But even more, I hope that our private sector reads and implements those same principles. Don't think that, because you're in private enterprise, you're somehow exempt from the problems that plagued the launch of healthcare.gov. You aren't.
As part of the release of the Digital Services Playbook, the White House announced that Mikey Dickerson, an engineer from Google who was part of the team that helped fix healthcare.gov, will serve as the new Administrator of the U.S. Digital Service and Deputy Federal Chief Information Officer. He is also a keynote speaker at the O"Reilly Velocity conference in September.
If you read some elements of the press, it's easy to think that healthcare.gov is the first time that a website failed. And it's easy to forget that a large non-government website was failing, in surprisingly similar ways, at roughly the same time.