The case for proven technology in critical systems

Software engineering has a strong pull towards the new: new frameworks, new languages, new infrastructure tools. Much of this is positive. The ecosystem advances because people experiment.

When a system supports casework, handles citizens' personal data or underpins an operational service, however, the calculation changes. In those contexts, choosing established, unremarkable technology is not a compromise. It is a deliberate decision.

What we mean by proven technology

Proven technology is technology that has existed long enough for its failure modes to be well known. PostgreSQL, rather than a database released last month. React, rather than a rendering library with 400 GitHub stars and a persuasive README. AWS services that have been generally available for five years, rather than those still in preview.

Proven does not mean old or inferior. It means predictable. When something fails at 2am, as it eventually will, the team should be able to find established answers on Stack Overflow rather than filing a GitHub issue and waiting for a maintainer to respond.

The hidden cost of novel choices

Every novel technology carries a cost. The team must learn it, the hiring pool shrinks, and debugging takes longer because fewer people have encountered the same problems.

On a side project, that cost is acceptable. On a system that the public or frontline staff rely on every day, or that holds sensitive personal data, it is a risk that requires justification.

The pattern is a familiar one: a project built on a fashionable state management library that the original developer understood and no one else did, or a deployment pipeline built on a tool that changed its API twice in six months. The technology was interesting; maintaining it was not.

Where this matters most

Government services, policing systems and any setting in which the consequences of failure extend beyond a poor user experience. If a data synchronisation job fails silently because of an edge case in a library chosen for its elegant API, the result may be an incomplete record in front of someone making a decision about a person.

In these environments, we default to the most established option that meets the requirements: PostgreSQL over a newer alternative, server-rendered pages over a complex single-page application where the use case is simple, and REST over GraphQL where the data model is straightforward.

This does not mean we avoid newer tools. We use them regularly where the problem genuinely requires them. The burden of proof, however, rests with the new technology, not the proven one.

Our approach

Before introducing any technology into a project, we ask several questions. Can we recruit for it? Has it been in production elsewhere for at least two years? If its primary maintainer disappeared tomorrow, could we still operate the system? If the answer to any of these is no, we require a compelling reason to proceed.

For the systems our clients depend on, reliability outweighs novelty. The best technology choice is the one nobody notices because it simply works.