The DMV website is so bad that it makes me want to go to the actual DMV. Nothing else in the world can do that.
There is a lot of rightful complaining about inefficiency of government contracting. There exists no shortage of reasons why they’ll overpay for things: cronyism, nepotism, legalized corruption… But why are the software products so terrible? Why don’t the $550 million dollar database initiatives yield software that can do simple things like, uh, search the database?
(It’s certainly not because they’re underpaying.)
In government work the acquisition process is broken in a particularly insidious way for software products.
Please Submit in Septuplicate
In another life I was a Marketing Assistant for a top 100 US general contractor. Part of my job was assembling proposals in response to RFP’s (Requests For Proposal) by companies who wanted to build a stadium, hotel, casino, etc…
We also did government jobs. I could tell with my eyes closed when gov’t RFP’s came in because the envelopes were three or four times as thick as is typical. I dreaded them.
A proposal for a large commercial job–like a 14-floor hotel–would be assembled into three separate four-inch ring binders for presentation. They would then be sent, along with an electronic copy on disc, to the entity who issued the RFP. It was a lot of work, but when you’re asking someone to pay you $60,000,000 that’s not unexpected.
The government proposals, on the other hand, could consist of between 15 and 30 (not a typo) ring binders in sizes I was unaware of until I took this job. Do you know what 30 six-inch ring binders of paper weighs?
It would take me 10 minutes just to load it into FedEx via hand truck from my car. And this would be for something like a military barracks, I’m not talking about skyscrapers or stadiums. I can’t imagine what the guys building bases go through. Not to mention that it was much more common with government jobs to have several rounds of these insane RFP’s.
On top of the bulk of the material to produce, they also had to be fastidiously put together in weird physical formats with certain labels, or even certain brands of label. These were to be placed at specified Y coordinates on the page at the beginning and end of each section among other very specific requests. It was also typical for electronic copies to be requested in file formats that were a decade old.
Software and web development isn’t construction, but I’m willing to bet the process of bidding is similar. There is a lot of unnecessary time and effort that goes into bidding the government. (It also helps if you know a guy ;) So when New York pays a consultant fee of $722 million dollars for time clock software that’s seven years behind schedule and doesn’t work…
It makes me sad, but it does not make me surprised.
Filtering For Mediocrity
The mindset that focuses on obnoxious minutiae and demands septuplicate-plus hard copy requests can certainly inflate project costs 7–10x. But why is it so expensive and nothing works? It’s because there’s no way you’re going to get competent programmers working for you using systems like this. In fact you’re going to specifically filter them out.
Programming is, by definition, a game where the winners and losers are separated on a huge scale. Pretty much all programming shares the trait of putting more work, often a lot more, up front in order to create something that will give you outsized value in the long run. It’s about creating systems for solutions (systems = programs, get it?) rather than the solutions themselves.
A strained metaphor: building a calculator vs. working out a problem with pencil and paper. Building the calculator is extremely difficult in comparison, but once complete the rewards are vast. A winner in this scenario, a team than can build a calculator versus one that cannot, win massively in perpetuity. And they can use/improve their calculator to build other stuff, like a computer…
So if your initial system or program is poor at the outset, or does not work at all, you lose massively. This is why tech debt is so insidious. It’s also why the legend of the 10x programmer persists. There is truth to it somewhere under all the breathlessness and trucks of cash being dropped off to millennials in Palo Alto. I think the truth is this: the 10x programmer may or may not exist, but is so rare that it probably doesn’t matter. However, the -10x programmer is quite common and is much more likely to affect a project than the counterpart.
The government’s current vendor acquisition pipeline is so pointlessly wasteful and time consuming, that it weeds out the sort of companies you want working on your technical problems and furthermore specifically selects for terrible vendors. Which is how you end up with terrible city government sites and on a larger scale CIA, FBI and DHSA databases that are unsearchable, and won’t talk to each other.
Great hackers see problems and are compelled to solve them. There’s been a lot of ink spilled by people smarter than me on exactly what makes developers great, so I’ll quote Paul Graham’s essay Great Hackers:
It’s pretty easy to say what kinds of problems are not interesting: those where instead of solving a few big, clear, problems, you have to solve a lot of nasty little ones. One of the worst kinds of projects is writing an interface to a piece of software that’s full of bugs. Another is when you have to customize something for an individual client’s complex and ill-defined needs. To hackers these kinds of projects are the death of a thousand cuts.
The distinguishing feature of nasty little problems is that you don’t learn anything from them. Writing a compiler is interesting because it teaches you what a compiler is. But writing an interface to a buggy piece of software doesn’t teach you anything, because the bugs are random. [3] So it’s not just fastidiousness that makes good hackers avoid nasty little problems. It’s more a question of self-preservation. Working on nasty little problems makes you stupid. Good hackers avoid it for the same reason models avoid cheeseburgers.
What about the government proposal process, riddled with nasty little boring problems, is going to attract great talent to work on our country’s infrastructure? Nothing. In fact, it will repel them.
The best way to fix this would be to scrap the clunky bidding process and replace it with one that’s an interesting problem to solve. Then again, they’ll never be able to hire the person who could do it.
Wade Meredith has been designing, writing, and programming since 2005. All opinions expressed are his own and do not reflect those of his employer, friends, acquaintances, or other associates. His personal website is WadeMeredith.com.