Gall’s Law, or Why Government Software Fails

The world’s best software is developed iteratively. The public sector's should be too. In 1978, the US Department of Defense laid an accidental foundation for decades of underperforming federal software projects. The language of regulation MIL-STD-1679 mandated the use of what we now call waterfall development—wherein projects only progress linearly, one phase at a time, working backwards from fixed end requirements. As is often true of well-intended policies, this rule rapidly metastatized as a template across the government while its effects were still being investigated. And by the time the costs became clear the damage was done: software projects increasingly gestated so slowly that they often only finished after underlying capabilities and needs had long moved on. This era also isn't quite over. The fruit of this original sin is still observable across the public sector today, where waterfall processes still lurk like institutional asbestos.

The Alternative

If you’re constructing a skyscraper or a bridge, it makes sense to do the bulk of the planning and engineering in advance. You don’t want to find out halfway through that you’ve chosen the wrong steel or support structures. Given that the physical constraints—along with expected human usage patterns—are predictable and narrowly defined, you have most of the required data in hand before you begin.

In contrast, software is built for evolving dynamics that are squirrelly by nature. It’s not until you release code into the wild and observe how users actually interact with it that you get the data you need most. Hence why the private sector abandoned the waterfall long ago for various Agile development models, all of which are premised on Gall’s Law:

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.

If you want your software to actually work for its users—whether that’s your own staff or the constituents footing the bill—you must begin with a simple system from the getgo.

1. Start with the largest use case

In Silicon Valley, every startup lives or dies based on what we call product-market fit. You spin up the minimum viable version of a product that addresses one big want or need that you suspect exists, then you go find out for sure. While you may have hunches or pencilled plans about how you might expand the product for other use cases later, none of that matters until you first validate that people truly value what you have so far. 

This process is never clean, and the world’s best startups didn't always get it right first try. They simply committed to iteration: they shipped, observed, adjusted, and then shipped again—and so on forever.

Any other model will perform worse forever, and not by a small margin. 

What if I have a mandate to build for multiple use cases?

Start with the meat anyway. The ultimate roadmap can still have all required use cases on it, including the fringe ones. But the way to meet them all to excellent results is to start with the 800lb gorilla. The learnings from that pilot then inform the rest.

2. Get closer to your users

The most predictive metric for any software project? The organizational distance between developers and users. The more that you’re coding in a silo, the worse your output will be. 

While we cover this more in Seeing Like a Taxpayer, feedback loops are the oxygen of any strong development process. You must make it easy for users to tell you what they hate, what they don’t understand, and what isn’t working like they imagine it should. The entire surface of your software—especially in its earliest stages—should be littered with prompts that encourage this kind of sharing.

You also can’t depend on users taking this step on their own initiative. You must go to them, both to observe how they navigate and to ask them to explain their POVs. Users have deep intuitions about how things should work, and good software has to meet them at this level—regardless of how “unsophisticated” their intuitions might seem or be. More elegant solutions simply don’t matter if they don’t work for the users you actually have. 

How can anyone tell if they’re close enough to users?

The golden rule: if a group of taxpaying users were to sit in the room and watch you map out a feature, would they happily make their tax contribution after? Either they witness someone advocating for viewpoints like their own or they don’t. If a vendor isn’t sure how this would go, that’s its own answer.

3. Use the right team structure

Project managers are important. Someone has to keep the emails and tickets moving. But someone must also be empowered to ensure the right things are being done. When leading software makers design something new—whether for internal teams or billions of users—they use product managers to align their engineers, users, and overall budget. 

The big difference between the two roles: a product manager isn’t paid or promoted for merely getting units of work done. Their compensation is tied to how well they steered the project to the right outcomes, as judged by how users respond. While the actual job title doesn't matter, making your leads own their results is what produces the alignment.

Does GovTron provide a product manager for every project?

We use a talent partner model. We find and vet Silicon Valley software engineers, designers, and product managers eager to help the public sector. We then assign them where their experience and temperament is likely to add the most value. For smaller projects, one of our principals will operate as your chief product manager. For larger ones, we’ll match you with a top candidate. (As our focus is on reusable components, this is often more budget-friendly than it sounds.)

4. Leverage modular contracting

To cure the defects of legacy processes, the federal government has increasingly championed breaking down software development into discrete stages. 

Instead of writing a requirements-heavy RFP and then selecting a single bidder to see it all the way through, most projects can be done today as a succession of smaller iterative steps. The first vendor can help with user research and outlining the pros/cons of available solutions, thus producing a nimbler and more future-proofed gameplan. The actual implementation can then often be subdivided to other vendors according to their various strengths, thus maximizing alignment while also minimizing dependency and lock-in.

Where can I read more about modular contracting allowances for my situation?

For federal projects, the main allowance is via FAR 39.103. Many states have similar exemptions, with more set to follow suit. We'll be publishing a more complete guide on this subject soon.

5. Be wary of cheap claims

The Department of Defense has learned from its missteps of the 70s. Beyond repenting for its waterfall mandate, it's also grown wiser to the gap between what vendors promise and what their business models actually encourage them to do. It's trivial for a firm to slap the term Agile on its website while not fully adopting the spirit of it. This in mind, the Defense Innovation Board released a report on Detecting Agile BS in 2019.

Some of the classic red flags it identified:

• Planners working too far away from real users

• Vague feedback loops 

• Treating requirements as the important thing

• Not iterating quickly enough

• Too many vendor employees saying “it’s not my job”

We co-sign these observations, and have built our operating model accordingly. It’s time to bring the best of what we know really works to the public sector.