Computers are eating bureaucracy. This should come as no surprise. Rigidly and programmatically checking a series of boxes is computers’s bread and butter. Computers eat forms for lunch. Automated computer systems are faster and more efficient at virtually everything a bureaucracy does. So naturally the government here in the U.S. is building its latest bureaucracy, the Federal insurance exchange mandated by the Affordable Care Act, as an online-only endeavor. Recent news stories have widely covered the failures in the system, both on the customer and insurer sides. The news has also widely covered the Canadian contractor CGI that is building the site for the government.
It is impossible not to notice that this is not how Silicon Valley makes consumer websites. Corporate internal websites where functionality trumps interface design are often made by big contractors, and they are often kludgy nightmares. But consumer website startups begin with a concept and build up a team of designers and coders who continuously iterate on interface and featureset questions. In a some cases the design chops of the team seem to be more valuable to potential investors or acquirers than, you know, things of actual monetary value like ad sales or revenues or even active users.
That kind of workflow is often not possible when a contractor does the work. Soon they have put a lot of poorly documented in-house ideas everywhere and the costs for someone else who wanted to get up to speed increase. If they follow good coding practices and comment clearly they are acting against their economic interest. That’s a bad conflict to have.
Every new responsibility of government bureaucracy (and a significant portion of existing responsibilities too) will be digitized. The result will be faster, more efficient, less labor-demanding, and less corrupt — if the software is designed well.
It’s time for government to adopt best practices for software design. There is no law of the universe that says only private companies can make good software — good software has been made by loose groups of open source contributors, by companies, by universities and by individuals working alone. Bad software has also been made by groups of all those types. Government too can make good software by looking at what’s similar among successful institutions’ approaches: build a team from a small size up and incentivize staying on; document everything; use a continuous process of feedback and improvement rather than a ‘ship date’ model; test long and hard. There are more best practices that are pretty well documented out there, but that’s a start. I see no reason government couldn’t utilize these principles and create powerful, money-saving, service-providing software that replaces massive bureaucracies with small, experienced teams of programmers.
And the alternative, I’m afraid, is that the government’s hamfisted approach to semi-privatized contracting will earn it ill will and low expectations. This will lead to worse software from the government (though not necessarily less of it — even bad software is much cheaper than humans). In short, the government needs to learn to code, because computing is eating governance just like it’s eating everything else, and increasingly governing and coding are the same thing.