Structures, Culture

Blaming software that fails gets us little in the way of fixing the problems that government faces. More helpful is to understand the structures and culture that created the software, because they determine not just how the software works but how the whole system operates.

Formally, the tech implementers are not charged with building services that meet users’ needs or achieve policy goals. Their job is simply to meet a predetermined list of requirements. These are often exceedingly specific, but nowhere in government documents will you find a requirement that the service actually works for the people who are supposed to use it. The systems are designed instead to meet the needs of the bureaucracies that create them—they are risk-mitigation strategies for dozens of internal stakeholders. And they often fail even at that task; trying to be all things to all people, they’re unable to make any reasonable tradeoffs for the sake of usability.

Policy Is King

That public servants get held accountable to process over outcomes is well known; I do not presume to know how to change this, though I desperately wish I did. What I do know is that the perverse effects of glorifying process are far greater in technology, for the simple reason that there are so few people in government who understand tech. Rigid, overly specific interpretations of law and policy are hard to avoid when those doing the interpretation can’t evaluate the work for themselves.

Policy people tend to see those who implement the policy decisions they make as being far below them in the pecking order, perhaps even at the bottom of it. OMB was the pinnacle of that pecking order. In other words, No, thank you, that’s lowbrow stuff. That’s not the kind of thing we do in powerful places in government.

Policy Complexity

None of the modernized states were able to avoid accruing backlogs, and few of them seemed to do much better than average in terms of scaling to meet demand. The problem is that the modernization projects all sought to “add functionality” — more layers of paint — or just to move to more modern infrastructure, particularly to the cloud. None of them targeted serving clients better or scaling to meet demand. If the people running the systems had set scale as a goal and truly analyzed their bottlenecks, they would have recognized the need to rationalize and simplify the accumulated layers of policy and process along with bringing in new technology.

Legacy Infra

... and because tech investments must always be pitched as adding some new capability to the system (rarely just renovating what already exists), each piece of the system gets built in different technology paradigms from different eras... The system is not so much updated as it is tacked on to. Over time, new functionality is added, but the system never sheds the core limitations of the foundational technologies. At the same time, it becomes enormously complex and fragile... It becomes harder and harder to support the technologies in the lower, older layers, while the more recent layers require constant updates and patches. The paint cracks.

Decision Making

Arguments about what is or isn’t required happen all the time, but they are much less likely to lead to a suffocatingly risk-averse answer when the people involved in the argument understand the domain... it is highly unlikely that anyone else in the debate — likely to be dozens of people in dozens of different roles — had any basis on which to judge whether an ESB was a good thing or a bad thing in this context. Thus, to nix the ESB, dozens of people in dozens of different roles would all have had to agree to jeopardize their jobs over a recommendation they didn’t understand. These discussions tend to function as a vetocracy, in which it takes all thumbs up in order to accept the risk, and only one thumbs-down to stick with the less-risky option. The ESB stays.

Scope of Requirements

Government’s obsession with requirements — voluminous, detailed requirements that can take so long to compile the software is obsolete before it’s even bid out—stems from a delusion that it’s possible to make a work plan so specific that it requires no further decision-making. You hand it off and the developers just do exactly what they’re told. Why not let those developers choose the best tool or platform for the job?

But the goal in government seems to be to drain the job of software development of any opportunity to exercise judgment... it’s particularly destructive when hardly any of the people writing the work plan have much basis for their decisions either.

Build vs Buy

Government procurement teams have a terrible habit of contracting for bespoke software when they could buy commercial products — partly because we tell these teams to collect every possible requirement they can think of, which encourages and even calcifies arcane practices within the departments they serve.

Owning and Building Products

It can’t just be a project that was contracted for, developed, tested, and declared “done.” You need to own the code, and you need to be able to change it to meet your needs... you must have the core competencies to support a living, ever-adapting system. Government knows how to acquire technology. What we need to acquire are capabilities.