While the rest of the world has evolved to a place where we can track anything at all times and order anything from anywhere, government has been hopelessly stranded on an island in 1993.
Normally, lots of people go through their lives barely interacting online with the government. If you are a U.S. citizen, regularly pay taxes, and don’t need food, housing, or health care assistance, you are probably only annoyed when you have to do something such as apply for a passport or renew your driver’s license, and even then your annoyance level is minimal.
But during a crisis, a lot more of the population suddenly needs the government’s help, and they are then shocked!— simply shocked!—to discover that those interactions are mind-bogglingly terrible. If you are one of the millions of people who attempted to file for unemployment benefits, stimulus checks, or small-business loans in any of the 50 states, you know of what I write. If you haven’t had this experience, you at the very least saw the viral clip of the governor of New Jersey putting out a call, on live TV, for COBOL programmers—a language that hit its prime in the 1960s. The tech community had a good laugh at the New Jersey government’s expense, and the rest of the world saw this as indicative of everything that is wrong with government technology. The systems are ancient and held together with the language equivalent of brittle masking tape. The applications are onerous and take forever to fill out. Assuming you can even access an application, given the rate that government systems seem to be crashing. Once you fill something out, there is no way to find out what is happening with your application. Yes, of course you want to track it the same way you track a UPS package and no, of course you cannot do that.
Those of us who have worked in government and around government technology are not at all surprised by this state of affairs. Of course the state unemployment systems are written in a 60-year-old programming language. Of course there’s no way to find out the status of anything you’ve submitted, ever. Of course the sites are crashing. Government hasn’t kept up with the times technologically for a number of reasons, most significantly a lack of market pressure to modernize and a failure to grasp the critical role that technology now plays in delivering on government’s promises and policies.
The first thing to understand is that while it might be funny that government relies on one of the first programming languages ever invented, the language alone doesn’t mean that systems must be terrible.
“If you understand what a user understands and wants to get done, you can design a good interface no matter what technology you have,” says Chris Riesbeck, an associate professor of computer science at Northwestern University, who used to code in COBOL back in the ’60s. “There might be some popular techniques in modern user interfaces that some older languages might not be able to support. But you can use COBOL to make a web service these days, which means the front end can be any whizzy thing you want.”
The real reason government systems tend to be terrible runs much deeper than language. In the 1960s, the government, along with the private sector, began moving from being a solely paper-based organization to one that used computers. At this point, computers weren’t supposed to be user-friendly, in part because that term hadn’t been invented yet. People were happy they didn’t have to write programs on punched cards, and that they could get computers to handle complex systems previously done manually. If it was complicated to get the computer to do that work, that was just part of the magic of the electronic age. It was an unspoken assumption that any computer program would come with a manual, and probably training, on how to use the system. No one thought about how the general public might use these programs at home because the personal computer didn’t exist yet.
Then came the ’90s. A lot of the world upgraded their old systems to more modern languages. Some did not. But suddenly with modem speed increasing and the rollout of broadband and DSL, people had the ability to do things from their home computers that previously had been done either by mail, phone, fax, or in person. Around this time two things happened in the private sector that did not happen in government. One was that private-sector companies saw that technology was critical to how they were going to be interacting with their customers, and began expanding their tech teams to meet that need.
In 1998, I worked at an advertising agency that maintained IBM’s website. That is correct. IBM, which at that time was supplying 70% of the business world with computing power, did not have an in-house tech team maintaining its website. The advertising agency had a floor full of people who knew the popular coding languages of the day, or had graphic design or user experience know-how. I don’t know if those consumer-facing people existed at IBM or not, but when the CEO of IBM discovered he couldn’t navigate to IBM’s latest direct-to-consumer PC in three clicks on their website (people were really into things being accessible in three clicks in the ’90s), it was easier to just ask the people who also designed their ads to also fix their website. At that point, websites were only starting to be seen as something more than a silly thing young people were into. So in 1998, IBM did not have an in-house team maintaining their website. Today, it has more than 100 people on its digital growth and commerce team who are responsible for all aspects of IBM.com. Other industries that also had to staff up robust in-house technical teams included banks, airlines, and insurance companies.
Government, however, did not make the move to bring tech talent in-house. This is true at the federal, state, and local level. Yes, there were IT teams staffing up in government who did things like make sure everyone had email and that the printer worked. But government did not staff tech teams, in part because people in government did not see the growing connection between technology and delivering services for Americans.
By and large, paper processes remained on paper and in-person processes remained in person. In some cases, this was because some government processes really do need to be conducted in person. A citizenship interview, for example, follows standard questions, but immigration officers also rely on a gut feel that can only happen in person. Interviews to help families find temporary housing are also an -in-person process only, which allows case workers to not only better understand a family’s needs, but also to feel out whether they’re looking at a domestic violence situation. In some cases, government likely didn’t move online because its processes were so old and complex that the idea of building a computer system to replicate these processes seemed like a Herculean task. In some cases, even when Congress passed mandates that required computerization, federal agencies didn’t budge. In 1996, Congress mandated that the U.S. automate both entry and exit screenings into the country for foreign nationals. The exit part of this system still doesn’t exist, despite at least seven calls from Congress and the presidential administrations after 9/11, in 2005, 2013, 2016, and again buried in the notorious 2017 executive order last year that also included the “Muslim ban.” The mandate has gone unfulfilled in large part because no agency has had the technological expertise to even conceptualize such a system, let alone build it, no matter how much Congress may want it to happen.
The second thing that began to happen in parts of the private sector, which bypassed government, is that people began to understand that user experience was a thing. And not just a thing that was a nice-to-have, but a thing that meant the difference between your site dying like MySpace or taking over the world like Facebook.
The private sector began to learn about the importance of user experience as they opened up their systems for the world to see. Think, for example, about the travel industry. Back in the day, travel booking systems were so complex and annoying to use that an entire travel agent industry blossomed based in large part on its ability to use travel mainframe systems, such as SABRE, to book tickets. You had to know the right keystrokes and combination of commands to get the vacation you wanted. Consumers could access these systems from home via early dial-up programs such as Prodigy and AOL, but according to a New York Times article from 1992, booking travel online was “almost as good” as using the telephone. SABRE grasped the importance of being easy to use for consumers and launched Travelocity in 1996. Other travel booking services leaped into the fray as well, and eventually those systems evolved to be user-friendly enough that travel agency giants such as Thomas Cook went out of business. In an industry like travel, there is clearly a consumer who will take their business elsewhere if booking a trip is hard.
But government has been slow to realize the importance of user experience in delivering on its agency mandates. In part this is due to the fact that consumers who need government services have no option but to get those services from the government. You can’t go somewhere else to get a pothole filled or to find subsidized housing. This lack of pressure means that government has been able to exist in a subpar technical environment for far too long. It also means that government doesn’t get the benefit of the feedback loop that the private sector does. People will come to government for passports or food assistance no matter how terrible the experience.
By the 2000s, many business saw that their choice was to move online or die. But government didn’t face that kind of pressure. So while the rest of the world moved online, government often stayed paper-based. When government agencies did move online, they did it by hiring contractors rather than building in-house teams, in part because this was easier than creating whole new job categories in a bureaucracy where hiring is highly regulated, and in part because, again, those in government failed to grasp that technology was now an integral part of how they delivered services.
To make matters worse, when government brought on contractors it often didn’t go very well. It still doesn’t, in part because of that missing technical talent. It’s hard to oversee a giant system build if you’ve spent your career overseeing paper-based processes. As a result, government is rife with huge contracting system failures, starting with healthcare.gov—the website critical to the rollout of Obamacare, which launched months late and millions over budget—and continuing through today with the state unemployment systems crashing left and right. Any technologist working today knows to design systems for the worst possible scenarios, including the greatest possible number of people accessing a system at a time. You wouldn’t design a bridge to hold the average number of cars passing over it and no more. Tech systems are the same. But typically there isn’t anyone in government to press contractors on points like this. And contractors have no incentive to raise these points on their own because when their systems fail, they are brought back in for another round of work and more money. So you end up with a system that crashes when people need it most.
While the rest of the world has evolved to a place where we can track anything at all times, order anything from anywhere, and apply for things at midnight from our couch, government has been hopelessly stranded on an island in 1993. Tracking where an application is in a process is now not only user-friendly, it is essential. But because government skipped out on a lot of the technical progress over the past two decades, tracking where something is in government isn’t as simple as flipping a switch. The basic architecture that you would expect to find in any modern company in the ’90s is likely to still be a paper-based process in government. Or if not paper-based, then something that lives on one person’s computer in Excel.
More critically, government is only just now learning that policies and benefits don’t exist in the world without thinking through a user-friendly implementation piece. Yes, government offers unemployment insurance for millions of Americans who need it. Yes, the money is there if you ask for it. But no, it cannot provide that insurance without a functioning website. Even if the website functions, government cannot provide that insurance to people if the forms are too confusing and applicants swamp the help lines with desperate calls.
This has been true of government interactions for a long time, but it was a secret that only the neediest, the most marginalized, the people on the fringes knew. In Michigan, the people filling out the world’s longest application form for public assistance knew it. Across the country, immigrants applying for green cards only to have their applications lost or stuck somewhere in the system knew it. But now it’s not just the quiet populations we don’t talk about who need government. Now we all need it.
There are people who have been working to change the way government functions in exactly this area. Sometimes they are called digital service teams or innovation teams. Sometimes they are a group of people in the Public Works department who think government should be not only by the people, but for the people, especially where people need government most. Bit by bit, pieces of government are becoming user-focused. Teams are working on improving benefits applications in California, Vermont, Michigan, and elsewhere. But this work is slow, and it is hard. Catching up with 30 years of thinking on technology and being people-centered doesn’t happen overnight. And in the meantime, if you know of any COBOL programmers, send them to New Jersey.
https://www.fastcompany.com/90495309/why-government-websites-fail
