Familiar systems often carry unseen dependencies

At some point you stop thinking about a system and just start using it. It happens gradually. At first you notice everything — it's new, you have to learn how it behaves, you see where the edges are. Then, over weeks or months, those edges blur. It works, so your attention moves on to something newer or louder. It just slips into the background.

That's not carelessness. Nobody can keep every system front of mind at once. There are newer problems, more pressing things. Reliability is what lets you trust something enough to forget about it. That's probably just how attention works. It has to be that way.

But a system doesn't get simpler just because you've stopped looking at it. The dependencies are still there. The assumptions are still there. The connections to everything around it are still there. They don't go away. You just stop seeing them. And once you stop seeing them, they accumulate. One small change. Then another. Neither seems particularly important at the time.

A small integration gets added because it's convenient. A workaround goes in because there isn't time to do it properly. Someone moves a folder. A script stops working. Another script is written to keep everything running. A shared spreadsheet that started as a temporary checklist slowly became the only place where certain decisions were recorded. No one scheduled its upkeep. No one owned it. It just kept going, and after a while nobody even thought about it. Each decision is small enough to seem reasonable. None of them is written down. They pile up invisibly until the system is carrying more than anyone intended and you can no longer trace where it came from.

Something else happens as systems become familiar. We stop asking questions. A new system invites questions — what does it do, what does it depend on, what happens when it fails. A familiar system invites assumptions. The questions were answered long ago, or so it seems. Asking them again feels redundant. It might even look like you're uneasy about something that's been working for years. No one wants to be the person who doubts a thing that's never let them down.

But the answers people gave when the system was new described something that no longer exists. The documented version is not what's currently running. The dependencies people understood at the start are not the ones that have built up since. No one updated the documentation because nothing was broken. Nothing needed explaining. The map is old. The territory has moved. Somewhere in the background, an automation still runs every morning. Nobody remembers who created it. Everyone assumes somebody else understands it. Nobody has asked in years.

Over time, dependency stops being a technical concept and becomes a habit. A team that's grown up around a familiar system gets into a rhythm that assumes it will always be there. Meetings are scheduled around its availability. The language of the system quietly becomes the language of the team. New hires are trained in its idioms without anyone explaining that they are idioms. The system stops being just another tool and becomes part of how the team works. Ask someone why a particular report still has to be generated every Friday afternoon, and you will often hear the same answer: 'It is just how we have always done it.' Not a tool. Just the way things are done.

None of this is visible during normal operation. That's what hides it. The dependencies just do their work. You only notice them when someone proposes a change. Then the estimates grow, the caveats appear, and it becomes clear what was actually holding everything together. No one could have predicted exactly where it would be heaviest. Looking back, though, it often seems obvious.

People often say change reveals fragility. Perhaps it reveals dependency instead. The fragility was always there. Change just removes the conditions that made it bearable. A migration, a vendor shift, a reorganization, someone leaving. The dependency doesn't suddenly appear. It was there all along.

Small changes accumulate quietly. Each one seems harmless. A tweak. A patch. Then something shifts, and everyone sees what has been building for years. At first, people blame the change itself. That's understandable. It's the first thing everyone notices. But the change didn't create the situation. It only made it visible. The structure was already there, built decision by decision, until it was strong enough to be noticed.

It's interesting how quickly we forget. Once the disruption passes, the pattern begins again. What was visible becomes invisible again. Perhaps we never really learn this. Or perhaps we do, and then, like so many things, we quietly forget.

Familiarity is not the same as understanding. Over time, the two quietly drift apart.

That may be all there is to say for now. Though it is worth noticing — if one can hold onto it — how quickly the noticing itself begins to fade.