Modern capitalism has showered us with abundance. With a few taps on a phone, an intricate Swiss watch can appear quickly at a doorstep, and we can placidly assume that it will work flawlessly. Buying something as big as a new public works truck is harder, but not insurmountably so.

Not all transactions work this well, unfortunately. When it’s time to change a sprawling enterprise resource planning (ERP) system at city hall, modern capitalism functions abysmally. “Software trouble” often appears in the form of public technology deployments that are too complex, too expensive, and too late in delivering their benefits, assuming they deliver benefits at all. In the first part of this series, I explored the preventive value of well-disciplined winnowing of software requirements alongside a passionate internal champion.

The phase of software trouble discussed here, the transactional process of software procurement, builds on this groundwork. Software suffers from the inherent tension between the public-service motives of government and the profit motives of capitalism, mediated through a procurement process full of information asymmetry and political pressures. Navigating this tension is not easy. A few tactics—favoring small and simple tools, feeling free to make partial use of larger software platforms, and engaging peer governments—can protect you from the worst of software trouble. They can obviate flawed deployments that, in the process of doubling down explored in the last part of this series, snowball into truly ruinous outcomes.

Monolithic Mirages

At the highest altitude, a government is a mashup of different systems, and it will always be. In doing the work of serving residents, information moves through a variety of computer systems, pieces of paper, and especially the brains of its employees. By the time they call me, many of my clients have gotten into software trouble essentially for aesthetic reasons. I found them chasing a mirage that a mashup of systems could finally be replaced by a pristine, monolithic solution promised by a software company.

I am not pessimistic about improving governments by tidying up the flow of information within them. Far from it. However, when I’ve seen success in this work, it has always resembled the painstaking work of refactoring code as a software engineer: a long sequence of low-risk, intellectually demanding but externally unremarkable improvements that walk an organization, spider-like, toward simplicity and efficiency.

In sharp contrast to this vision, monolithic software solutions are encouraged by a culture and context that cherish big procurements.

Bold, high-dollar contract awards help elected officials communicate to voters that they take an issue seriously. These contracts disguise an unappealing stream of small repairs to a clunky system with something that sounds and smells more like a new public works truck.

And a huge ERP migration delivers far better profits to vendors than subscriptions to small and simple software tools or high-touch process improvement projects.

Room to Hide

Dangerously, big procurements give software companies and implementation providers a lot of room to hide. Software trouble thrives behind complexity and the inertia of the procurement process. Misrepresentation about software features, quality, interoperability, or ease of migration can stay hidden until the vendor is locked in and it’s too late to easily back out.

While today I joke that my job is to talk cities and counties out of buying software, I’ve been on the other side of this dynamic. Fresh out of my Ph.D., at the beginning of my career in data science, I was a software engineer with a data science startup. My employer had built a variety of tools that had been internal force multipliers for its consulting work, and it was pushing to enjoy the higher margins of a software company. I advocated for narrowly packaging our best tools, getting them out into the world, and earning some honest money. I vividly remember my boss’s rebuttal. She said, “Tools are small and cheap. Platforms are big and expensive.” And so the tools we’d proudly built remained buried and underused within a sprawling cloud platform with expansive marketing claims and a price tag to match.

Pushback

The transactional dynamic is frustrating, even for the programmers who write your software. As a government customer, here are a few key ways to push back on it.

1. Simplicity. Transactional capitalism being so good at delivering Swiss watches, prefer software that resembles them. Shrink vendors’ room to hide behind complexity by preferring simplicity. Resist the hope of solving many institutional problems with a single technology project. Instead, be biased toward small, simple products with a single responsibility. Having been under the hoods of many cities and counties, the software solutions that amaze and delight public servants and residents overwhelmingly focus on narrow domains, like parking enforcement, work order management, or resident engagement. When a software solution’s purpose can no longer fit comfortably in your head, it probably can’t fit in the heads of your vendors’ engineers, either. Complex products are almost always worse than simple ones because nobody can think clearly about them.

2. Partial use. When working with a big complicated platform, don’t feel forced to use all of it. Often a big-name software platform involves ten or more poorly integrated products built by startups, then acquired by the big-name company through corporate mergers over time. One or two of these products are widely used and loved, while the rest are ignored, tolerated, or reviled. Usually, parts of your legacy systems can coexist with new software. In the technical analysis of a software solution, it’s key to ensure that the good parts of a prospective product can interoperate acceptably with existing systems you will keep for now.

3. Peer advice. Finally, engage your local government peers. A vendor representative, bluntly, has a strong financial incentive to tell any lies necessary to win your business. As reinforced by Tenet 12 of the ICMA Code of Ethics, managers of peer governments don’t have this incentive. Ask them what software they use and how they like it. Such conversations are synergistic with the bias toward small, simple tools. Small, simple tools are amenable to head-to-head comparison; sprawling and highly customized ERP deployments tend to be unique snowflakes where peer experience is less relevant.

Risk Mitigation

In the pressure it creates to repackage incremental improvements as grand gestures and the room it creates to hide behind complexity, the transactional mindset of modern capitalism is a huge challenge. It lies at the heart of software trouble. Yet it must be wrangled to efficiently deliver great services for residents. By favoring small and simple products, thoughtfully mixing and matching parts of larger products, and engaging peer governments to hear their experiences, the risks of software trouble can be mitigated considerably in the process of technology procurement.

Yet the risks cannot be eliminated completely. Even with the best brainstorming and transacting, it is still possible that flaws in an initiative will appear. The money and professional reputation you’ve already committed will make it hard to admit defeat. At that point, doubling down on a struggling software deployment becomes hard to avoid. Resisting the temptation to double down, the topic of the final post in the series, becomes the final defense.