The federal government should fire me. Like the thousands of other contractors who develop software for government agencies, I am slow, overpaid, and out of touch with the needs of my customers. And I’m keeping the government from innovating.
In recent years, the government has become almost completely dependent upon contractors for information technology (IT). So deep is this dependency that the government has found itself in a position that may shock those in the tech industry: it has no programmers of its own; code is almost entirely outsourced. Government leaders clearly consider IT an ancillary function that can be offloaded for someone else to worry about.
But they should worry. Because while they were pushing the responsibility for IT into the margins, the role of IT became increasingly central to every agency’s business. Computing might have been ancillary 20 years ago, when the only computers were the mainframes in the basement. Average employees never had to worry about them. But today, a computer is on the desk of every civil servant. Those servants rely on their computers to do their jobs effectively. Every day, they encounter new problems that could be quickly solved with a bit of web savvy, were there only a programmer there to help.
And they desperately do need help. Imagine not having Google to quickly find information; no Facebook or LinkedIn to find new colleagues; no instant messaging to communicate with those colleagues once you found them. Imagine having to ask for permission every time you wanted to publish content online, instead of being able to do it quickly and easily with a wiki or weblog. This is the state of computing in the federal government.
The government can no longer afford to outsource IT. It is core to the government’s business. If the government intends to do IT right, it should wean itself from outsiders like me and start doing the job itself.
What’s so wrong with contractors? Nothing, really; the problem is the processes they have given rise to. The pervading philosophy is that government is slow, inefficient, and incapable of quickly adapting to change, while private companies do things better, faster, and cheaper. In many cases, this is true; the government is by no means a well-oiled machine. But software is one thing that contracts do not speed up. Software developed under contract is much slower and much more expensive than any other form of software development still in practice. Here is how the typical IT contract evolves:
A low-level government employee complains to her boss about a problem. This could be anything from a bug in an existing piece of software to a gaping hole in her agency’s IT security. The boss has no programmers on hand to solve the problem, so he dismisses it.
More and more people complain about the problem until it gets attention from higher levels. But even thinking about a solution is expensive—months of paperwork must come before a contract is awarded and someone finally starts writing code—so the problem remains unsolved.
The problem leads to a calamity—a website is hacked, classified information is stolen, or electronic voting booths break down on Election Day—and leaders are finally motivated to solve the problem.
Procurement officers write a list of requirements for the ideal solution. Because they have little direct experience with the problem, they survey the workforce to get a sense of what’s needed.
The workforce’s version of the problem is condensed into a document called a Request for Proposals, or RFP. The RFP is then distributed to potential bidders, who will respond with a proposed solution and a bid based entirely on the contents of the RFP. Contractors cannot go directly to the users, the people who know the problem best. The RFP is therefore an indirect, highly edited communiqué from the user to the contractor, a substitute for the invaluable direct interaction between user and coder that guides any successful software product. But it’s too late: contractors are from here on out trying to solve what they believe the problem to be, not the problem that really is.
The contract is awarded. Months or years after the problem was first noticed, the first line of code is written. Over the coming months, the winning bidder will develop the solution off-site, hidden from the eventual users who could be providing valuable feedback.
The solution is delivered. Because the target users had such a small part in the development process, the solution falls short. It is hard to use and comes with an 80-page manual.
It should now be clear why the government is so far behind the times: it isn’t allowed to solve its own problems, relying instead on people who do not understand them. Two glaring faults doom the contracting process to failure. First, the development process is vastly different from that of today’s most popular software. Modern web applications are persistently watching their users and adjusting their code to make it faster and more user-friendly. Adventurous users can begin using these applications before they’re even finished, giving the developers invaluable insight into their users’ preferences. Without this constant feedback, the developers risk spending years on a product in private, only to reveal it to the public and find that nobody wants to use it. Such products are so common in government that they have earned their own moniker, named for their eternal home: shelfware.
Second, the paperwork required to simply start coding takes time and money. So, to even consider solutions, the problem has to be severe enough to justify months of bureaucracy. Why go through all that trouble just for a problem that would take a week to solve? The logic makes the taxpayer ill: the bureaucracy actually wants high price tags. The result is an organization full of easy problems that get no attention until they are big, expensive, and ready to boil over.
One such problem that may soon boil over is the terrorist watch list. For years, the list—created to monitor suspected terrorists and keep them from flying on commercial airliners—had inconvenienced innocent travelers. The problems were evident, but they weren’t bad enough to justify asking for help.
Then a toddler was kept from boarding a flight. Then a senator. At some point, this problem crossed the threshold, and the government issued an RFP for an improved database to manage the list. The $500 million contract was awarded to Boeing and a smaller company. After months of development, a congressional investigation discovered that the soon-to-be-deployed database could not perform basic searches for names, and was missing huge stores of valuable data. The National Counterterrorism Center had spent half a billion dollars on a tool that, while certainly complex, could not do things that you and I do every day from our home computers.
Why so much money for something that seems so simple? This frame of mind—that technology projects should be big, expensive, and time-consuming—has honest beginnings. Twenty years ago, computing was a niche. The government used computers to encrypt the president’s phone calls, simulate nuclear blasts, and predict the weather. The government paid private companies lots of money to build very complex systems. That’s OK, because tasks such as these required lots of computing power, so the biggest, baddest, most expensive system was usually the best. It didn’t matter that these systems were hard to use, because the only people using them were computer scientists. The builder of the system understood the user—the builder and user may have even worked side by side—and if the user ever needed the system to do something it couldn’t, that user probably had the skills to tweak the system. Computers were left to the computer people. Everyone else still used pencils.
But computing is now everywhere. Computers long ago fit on our desktops. Now they fit in our palms. But the government still acts like computers fill basements, and if you could sit down at a government desktop, this outdated mindset would be immediately apparent: on the screen would be websites reminiscent of the mid-1990s, without any of the web-based productivity and collaboration tools that define today’s Web. Expensive supercomputers still matter. But so do cheap, light web applications. Small, unassuming tools can change the way an organization does business. Such tools are commonplace online, but they do not get a second look from a government that expects and needs its technology to be expensive. Meanwhile, independent developers are at their keyboards, proving themselves willing to help a government that, as we’ll see, is slowly opening its arms to them.