It’s safe to say that Congress has never before passed a federal law whose primary mode of delivery is a web portal that will be used by tens of millions of people. And not just one portal, but a portal that serves as a gateway to numerous state healthcare exchanges along with the federal exchanges; a portal that must link up newly designed web pages and interfaces with legacy systems stretching from the Internal Revenue Service to the Veterans Administration to the Medicare and Medicaid systems, none of which are easily compatible or speak the same language.
Many in the tech community have tried to analyze what went wrong with the web launch. Some think the government shouldn’t have hired low-bid contractors, choosing agile development teams instead. There was also a lack of sufficient testing of the site before launch, but the site went live anyway because of political considerations. That the site’s code is not public has limited the ability of even savvy tech-heads to fully explain the many problems.
What is evident, however, is how inexperienced the federal government is when it comes to developing complicated technology systems unrelated to the defense department. Testing is certainly a major issue. Whenever a large or small tech company releases a new version of software, it is after months of assiduous testing of bugs and glitches in a beta version. Even then, the more complex the programs, the more problems there are. Microsoft for years has earned the reputation of releasing programs that are still flawed despite months of running the code through its paces. Some critics have faulted the administration for similar sloppiness, but in truth, the federal government didn’t have the option to do this kind of beta testing.
Imagine the political blowback if an early version of the site had been tested and then scrutinized by adversaries. They would have used the glitches as a compelling case to delay the implementation. Testing publicly only works when there is some consensus on what the outcome should be, which in almost all cases is the actual release of the product. If everyone agreed that the healthcare law was a good thing and required a first tier website, then you could have beta tested it extensively in order to make it better. But when a fair number of people would use the flaws revealed during testing as a way to torpedo the project, optimal testing just can’t be done. Given that, it would have been extraordinary if the site had been launched without major issues.
So, how can government deliver in a digital world? The British government recently revamped not just its websites but its approach to creating them, adopting the software development methods that are more reminiscent of Silicon Valley: open sourcing, collaboration and smallish teams. The failures of Healthcare.gov should spark similar changes in the U.S., but the problem with a partisan system of highly atomized political parties is that what works best for implementing policies is frequently trumped by the partisans wanting to prevent that implementation. Right now that means Republicans are determined to halt Obamacare, but it likely will mean Democrats adopting similar tactics when it suits them.