Last year I was made redundant from an NHS role. Around the same time, the team I worked in got a “new system.” Everything that used to live on paper — or, honestly, in something that behaved like a shared Excel sheet — was going digital.
I was still employed during the first few weeks of rollout, so I watched it happen. And the thing I remember most clearly is that it didn’t make anything better. The forms moved from paper to screen, and that was more or less the whole story. The same duplications, the same overlaps, the same unanswered questions. If anything, it felt more primitive than the retro spreadsheet it replaced.
I’ve been chewing on why ever since, and I think it’s worth writing down, because the failure mode is one every engineer will recognize once it’s named.
Paving the wrong path
There’s an old phrase in software: if you digitize a bad process, you get a digital bad process.
The engineering equivalent is porting a legacy codebase line-for-line into a new language and calling it a rewrite. The syntax is new. The runtime is new. But you carried every piece of technical debt across the boundary intact, because you translated the implementation without ever revisiting the design.
Policy is the spec. Software is the implementation.
Here’s the distinction I kept coming back to, and I think it’s the crux of the whole thing. In a normal project, requirements drive implementation. The spec says what the system should do; the code is one interpretation of that spec. When they diverge, you have a defect.
In public systems, policy is the spec and software is the implementation. Every required field, every workflow step, every deadline, every automated decision is a concrete interpretation of a policy. This is where policy stops being an abstract document and becomes something a real person collides with at 4pm on a Friday.
So when a policy says “provide tailored support” but the software only ships a single hard-coded workflow, the implementation contradicts the spec. Nobody signed off on that contradiction. It just emerged from the gap between the two layers — the same way a bug emerges when the code does something the requirements never sanctioned.
A dependency with a bus factor of zero
The part that still bothers me most is how the system arrived. No manager knew who built it. Nobody could tell me where it came from, who maintained it, or how it fit the existing workflow. There was no training.
Frame that in engineering terms and it’s absurd. This was:
- an undocumented third-party dependency
- deployed straight to production
- with no README, no runbook, no changelog, no owner
- and a bus factor of zero — not one person on site could answer a question about it
I only found out much later that it wasn’t even a UK system; it was imported from the US. That’s an unvetted external dependency shipped into a critical path, and the onboarding doc was the word “learn.”
We’d never accept this in a repo. We’d block the PR. But institutions do it constantly, because the people deploying the system and the people using it are separated by enough layers that the missing context never registers as a problem — until it lands on the person doing the job.
Accessibility is an architecture problem, not a UI problem
When engineers hear “accessibility,” we usually think keyboard navigation, screen readers, color contrast, text scaling. All important. But there’s a broader meaning that matters just as much:
- Can people understand what the system is actually doing?
- Does it adapt to different circumstances, or force everyone down one path?
- Is it clear who made a decision, and why?
- Can someone challenge a decision without needing extraordinary time, money, or expertise?
Those aren’t UI questions. They’re architectural ones. And you can’t fix an architectural problem at the presentation layer. If an API has terrible semantics, no amount of pretty documentation saves it. If the underlying service model assumes everyone follows the same workflow, a bigger button doesn’t help the person the workflow was never designed for — it just makes the dead end easier to click.
The NHS system had this exact shape. The interface was new. The model underneath it still assumed one path for everyone, and that assumption is the thing that fails people.
The silent bug tracker
Now the part I care about most, because it’s the one that generalizes to any organization.
A system can only improve if it’s allowed to learn. And a learning loop needs three things:
- Honest feedback — real signal about what’s failing
- A safe environment for producing that signal
- A transparent process for deciding what happens with it
Break any one and the loop stops closing.
Engineers already understand this, because we understand observability. Feedback is telemetry. It’s how a running system tells you where it hurts. Now imagine a project where every bug report is met with “why are you being so negative?” Give it a few months. The issue tracker goes quiet.
From the outside, that looks like stability. It isn’t. People just stopped filing.
if report_is_honest:
punish(reporter)
# a few weeks later
open_issues == 0
conclusion: "the system is stable"
reality: telemetry disabled, failures now silent
Enter fullscreen mode Exit fullscreen mode
This is survivorship bias applied to an entire workplace. The dashboards are green because you turned off the sensors. And in a lot of public systems right now, honesty is punished — you get told off, told to get used to it, or told that’s just how things are. So people stop believing they can change anything, and the signal dies. Not because everything works, but because reporting stopped feeling worth the cost.
There’s a second, quieter failure hiding next to it: collecting feedback you never act on. We do this with metrics all the time — we track something because we can, not because we have a process to respond to it. A thousand survey responses that feed no decision are just vanity metrics. Gathering the data isn’t the point. Closing the loop is.
Open source is the unlock — but policy has to evolve with it
I want to be clear: I think open source government infrastructure is genuinely one of the best things that could happen to public systems. For the first time, people who actually depend on a service — and the engineers who understand how it’s built — can participate directly. They can read it, contribute, file issues, propose fixes, and have their needs acknowledged in a place everyone can see instead of scattered across emails, complaints, and tribunals. That’s real power, and it’s worth being excited about.
But — and this is the whole point — that power only fires if the policies evolve at the same time.
You can have public repos, open issue trackers, documented architecture, transparent decision logs — and still run a culture where nobody dares say “this isn’t working,” because the last person who did got punished. Open code, closed culture. The loop is still broken; it’s just broken in public now. You’ve handed people a contribution channel and simultaneously made contributing unsafe.
So the two have to move together. Open sourcing the implementation while leaving the policy — and the culture around feedback — untouched just publishes the dysfunction. But open sourcing it alongside policies that actually welcome and act on honest input is where the potential becomes real: frontline staff and citizens stop being passive recipients and become part of how the system improves.
Because they’re the ones hitting the failures every single day, their lived experiences hold the potential for your best telemetry.
The actual shift
Most conversations about digital government ask: how do we digitize existing processes? That question gets you paper-on-a-screen. It gets you the NHS rollout I watched.
The better question is: how do we build systems that continuously learn from the people who use them? That’s not about replacing paper with software. It’s about designing institutions with a working feedback loop built into the architecture — where the reasoning behind a system is documented, its assumptions are explicit, structural problems can be reported safely, and changes are visible instead of vanishing into private procurement and closed meetings.
Under that framing, publishing the code is almost the last step. The important part is making the decision-making itself observable.
And notice that none of it is really about technology. Python, Java, or paper — the values underneath are the same: transparency, accountability, shared responsibility, and a loop that’s actually allowed to close. A system that only delivers a service is a system running blind. A system that learns from the people who build it and the people who depend on it is the one worth building.
답글 남기기