The Soviet Model of Software

Two Scenarios. One Right. Guess Which.

Scenario One. Two developers. Same system. Something breaks. Developer A messages Developer B: “Hey, that thing’s doing the weird thing again.”

Developer B already knows what he means.

Five minutes later, it’s sorted.

Transaction cost: zero. Latency: zero. Information fidelity: near perfect.

Scenario Two. Someone with an MBA sees Scenario One and panics. “Where’s the visibility? The accountability? How do we track this?”

So they add a ticketing system. A workflow. A manager who sits between the two developers like a human firewall.

Now when something breaks: Developer A logs a ticket. Manager triages it. Manager assigns a priority. Manager schedules a meeting. Both developers explain the problem in terms simple enough for the manager to understand — which strips out every ounce of nuance that made the quick fix possible.

Something that took five minutes now takes three days, four status updates, a priority classification debate, and a standup where everyone pretends to care about the burndown chart.

Which scenario is better? Obviously the first. Which do we keep choosing? Obviously the second.

The Ticket Is a Tribunal

But speed isn’t what makes Scenario One work. It’s the humanity.

When Developer A walks over to Developer B, something happens that no ticketing system can capture. There’s a shared eye-roll about the legacy code they both hate. Developer B says “oh god, not that module again” and they both laugh. There’s the offhand remark — “you know, I saw something weird in the logs yesterday too” — that accidentally reveals a second bug nobody knew about.

That’s not inefficiency. That’s where trust gets built. That’s how two people become a team rather than two resources assigned to adjacent workstreams.

A ticket has no laughter. No eye contact. No “by the way, while I’ve got you...” A ticket is a formal accusation dressed up as a request. Your code broke my code. Here is my evidence. Please fix it within the SLA.

Even when nobody intends it that way, that’s how it feels. The ticket system turns colleagues into complainants and defendants. Every interaction becomes a little tribunal.

Where Luck Lives

Penicillin — accidental contamination. Post-it Notes — a failed adhesive. Slack — a failed video game that accidentally built a great internal chat tool.

None of these came from a ticket. None came from a scheduled meeting with a predefined agenda. They came from the messy, unstructured space between formal tasks. The corridor conversation. The tangent that turns out to be the main event.

When Developer A walks over about a bug, and Developer B says “huh, that’s weird, because I noticed something odd in the authentication layer too” — that’s not scope creep. That’s discovery. Two observations from two different angles colliding accidentally. That is exactly how breakthroughs happen.

A ticketing system is designed to eliminate exactly this. By design. Tickets are scoped. They have boundaries. Solve THIS problem. Only this problem. Close the ticket. Move on. Don’t wander. Don’t wonder. Don’t notice the interesting thing at the edge of your vision because that interesting thing doesn’t have a ticket number.

You are building a system that is structurally hostile to luck.

No one files a ticket that says “let me accidentally discover something brilliant.”

Your Manager Is Gosplan

The Soviet Union didn’t fail because it lacked information.

It failed because it routed all information through a central node — Gosplan — that didn’t have the contextual intelligence to process any of it.

Your manager is Gosplan. Your ticketing system is the Five-Year Plan.

A factory manager in Vladivostok needed ball bearings. Couldn’t call Novosibirsk directly. Had to file a request to Moscow. Wait for approval from someone who’d never touched a ball bearing. Receive the wrong size three months later.

This is what happens when you force two developers who sit twelve feet apart to communicate through Jira. Almost precisely.

The Nasrudin Problem

Here’s the thing nobody says out loud: the ticketing system doesn’t solve a development problem. It solves the manager’s anxiety about not knowing what’s happening.

We’ve confused the manager’s comfort with organisational effectiveness.

In Scenario One, the work is getting done. Fast. With full context. With mutual understanding. But it’s invisible. No artefact. No audit trail. No dashboard with satisfying green checkmarks.

There’s an old Sufi tale about Nasrudin searching for his keys under a streetlight. A passerby asks where he dropped them. “Over there, in the dark.” “Then why are you looking here?” “Because this is where the light is.”

Ticketing systems don’t illuminate what’s actually happening. They illuminate what’s easy to track. We mistake the illumination for understanding.

Goodhart and Parkinson Walk Into a Standup

When a measure becomes a target, it ceases to be a good measure. That’s Goodhart.

The moment you add a ticketing system, you create metrics. Tickets opened. Tickets closed. Average resolution time. Everyone optimises for them.

Real scenario. Ticket: “Application crashes on login.” Developer discovers the crash is deep, architectural, would take a week to fix properly. Under pressure to close tickets fast, he wraps the function in a try-catch, swallows the error, redirects to a page reading “Session could not be established at this time.”

Crash gone. Ticket closed. Dashboard: green. Application: still broken. But now politely broken.

You’ve built a system optimised for its own measurement, not its own purpose. This is a near-perfect description of most modern corporate processes.

Then Parkinson shows up: work expands to fill the time available for its completion. But there’s a darker corollary — process expands to justify the existence of those who administer it.

The ticketing system creates work that justifies the ticketing system. The manager creates meetings that justify the manager. Workflow needs a workflow manager. Metrics need review meetings. Review meetings need minutes. Minutes need follow-up actions. Follow-up actions need a tracking system.

An entire organism that exists solely to feed itself. The bureaucracy metastasises. And like all metastases, it insists it’s necessary.

The Scale Exception

I’m not a complete anarchist about this.

Twenty developers? Fifty? Five hundred? You can’t rely on personal relationships at that scale. Dunbar’s number applies to codebases too. Distributed teams. Compliance requirements. Systems too complex for two people to hold in their heads. Yes, structured communication helps.

But introducing that system when you have a few people? You’re deploying an enterprise solution for a human conversation. You’re using a crane to pick up a coffee cup.

The AI Plot Twist

And now the part that should alarm you.

A developer sits with Claude, Copilot, Cursor — whatever. They work together exactly like Scenario One. “That thing’s doing the weird thing again.” AI has full codebase context. Responds instantly. They iterate. Refine. Test. Feedback loop measured in seconds.

The purest Scenario One that has ever existed. High-bandwidth. Zero-ego. Infinitely patient. Total context.

And what are organisations doing with it?

Approval workflows for AI-generated code. Review committees deciding which tasks “qualify” for AI assistance. Developers logging tickets to request AI access. Meetings — meetings! — about the governance framework around prompt engineering.

Inserting a governance layer between developer and AI is like hiring a translator between two people who speak the same language. The translator doesn’t add understanding. They add delay, distortion, and a monthly invoice.

And here’s the deeper irony: the AI is already doing the testing. It writes the code, generates the tests, runs them, spots the failures, iterates — all in the same conversation. The entire QA loop that once justified middle management is happening in real time. By the time you’ve filed your ticket requesting permission to use AI, the AI has already solved it, tested it, and written the documentation.

The ticketing trap isn’t just a human problem anymore. It’s interspecies now.

Leave It Alone

What we’re really doing is replacing trust with tickets. Social capital — shared context, mutual understanding, the ability to read tone — with process capital: workflows, approval chains, status meetings. Because social capital can’t be measured and process capital can.

The best systems in software — between humans, or between a human and an AI — are the ones that look informal to managers. So they get “improved” out of existence.

Two developers talking is not a bug in your process. It is the process. Working precisely because no one is managing it.

The most dangerous predator in this ecosystem? A well-meaning person with a Jira licence and a mandate to “bring visibility.”

Next time someone suggests adding a ticketing system between two developers who are already communicating — or between a developer and an AI that’s already producing results — ask them one question:

“What problem are we solving — theirs, or ours?”

Use the right process for the job.