The Ticket Nobody Closed That Became the Architecture
There's a ticket in our backlog from 2023. It's labeled "investigate performance issue in search." It has seventeen comments. The last comment is from eight months ago. Nobody closed it because nobody fixed it, and nobody fixed it because at some point the performance issue became the expected behavior, and the expected behavior became the architecture.
This is how a lot of architecture happens. Not through design. Through accumulation.
How Tickets Become Architecture
A ticket starts as a problem. Someone noticed something wrong and wrote it down. That's good — writing it down is better than not writing it down. But writing it down creates a false sense of resolution. The problem is documented. The problem is known. The problem is, in some sense, handled.
Except it isn't. It's just recorded. And recorded problems have a way of becoming permanent. The ticket sits in the backlog. The team works around the problem. The workaround becomes the standard approach. The standard approach gets documented. The documentation doesn't mention the ticket. The ticket is now invisible to anyone who wasn't there when it was written.
Three years later, someone asks why the search works this way. Nobody knows. The ticket is still there, but nobody looks at tickets from 2023. The answer is: because of a performance issue that was never fixed and eventually became the design.
The Archaeology of Old Tickets
I've started doing something I call ticket archaeology. Once a quarter, I go back through old closed and open tickets and try to understand what they were actually about. Not the surface description — the underlying problem. What was the system doing that prompted someone to write this down?
What I find is usually one of three things: a problem that was fixed and the fix is now invisible; a problem that was worked around and the workaround is now the system; or a problem that was never addressed and is still there, just accepted.
The third category is the interesting one. These are the problems that became features. The Calitoy Core blog has been writing about this — the gap between what the system was designed to do and what it actually does, and how that gap accumulates over time.
What to Do About It
The honest answer is: not much, in the short term. You can't fix everything that accumulated. You can't reopen every ticket and address every problem that became architecture. The system is what it is, and the team has built knowledge and workflows around it.
What you can do is be honest about it. When someone asks why the search works this way, the answer shouldn't be "that's how it was designed." The answer should be "there was a performance issue in 2023 that we never fixed, and the workaround became the standard approach." That honesty matters. It tells the team that the current state is not inevitable — it's the result of specific decisions (and non-decisions) that could be revisited.
The Tarosyn Dev team has been thinking about this in the context of technical debt — specifically about how to make the history of a system visible to people who weren't there when it was built. That's the same problem. The ticket is a record of the history. If nobody reads it, the history is lost.
The Ticket as Documentation
The best use of old tickets is as documentation of intent. Not what the system does — what someone wanted it to do, and why it doesn't do that. That gap is information. It tells you what the constraints were, what the tradeoffs were, what was considered and rejected.
The Spaxob approach to anomalies — treating unexpected signals as information rather than noise — applies here. The old ticket is an anomaly in the system's history. It's worth understanding what it's telling you.
Close the ticket or don't. But read it first. The Opened Terminal blog has been tracking some of these patterns — the ways that technical systems accumulate history and what that history reveals. The ticket nobody closed is part of that history. It's worth knowing it's there.