CelinQ Insights · No. 06

Designing without the fear of overwriting a colleague

How anxiety about clobbering someone else's work slows an entire practice down.

Some costs in a team's working life are loud. A crashed repository, a lost afternoon, a missed deadline — these announce themselves and get discussed. Other costs are silent, and the silent ones are often larger, precisely because nobody names them. The fear of overwriting a colleague's work is one of the silent ones. It rarely shows up in a retrospective, because it does not produce an incident to point at. It shows up instead as a subtle drag on everything, a tax that every architect pays a little of, every day, without quite realising they are paying it. This piece is about that fear: where it comes from, what it quietly does to a practice, and what it takes to actually remove it rather than merely manage it.

The shape of the fear

To see the fear clearly, watch an architect who works in a shared repository that they do not fully trust to protect their colleagues' work. They are about to make a change to a package that they know someone else has been touching recently. They hesitate. Maybe they ping that person first to check it is safe. Maybe they wait until the end of the day when they think everyone else has stopped. Maybe they make a private copy of the area they want to change, work on it in isolation, and put off the awkward business of folding it back in. Maybe they simply decide the change is not worth the risk right now and leave it undone. Every one of these responses is rational, and every one of them is a small defeat for the practice, because in each case the fear has changed the behaviour of a capable person for the worse.

The fear is not irrational, which is what makes it stubborn. In many shared-repository arrangements, the danger is real. If the underlying model behaves in a way that lets one person's save quietly win over another's — the pattern usually described, with unwarranted neatness, as last-write-wins — then overwriting a colleague is not a paranoid fantasy but a genuine possibility. And the worst part is that when it happens, it is often invisible at the moment it happens. The person whose work was lost does not get an error. They simply come back later to find that the element they carefully specified has reverted, or the relationship they drew is gone, or the attributes they set have quietly returned to older values, with no message, no marker, and no obvious culprit. Having been burned by this once, or having heard a colleague describe it, an architect learns caution. The caution is the fear, internalised and turned into habit.

The overwrite is bad. But the fear of the overwrite is worse, because it is present on every ordinary day, shaping a hundred small decisions, whereas the overwrite itself is rare.

What the fear costs, concretely

It helps to trace the specific behaviours the fear produces, because each of them maps to a real loss for the team.

The first is serialisation — the informal, unspoken agreement that people will take turns rather than truly work in parallel. When a team is afraid of colliding, it starts to behave as though the model can only safely hold one editor at a time in any given area. People wait for each other. They coordinate not because coordinating adds value but because they are afraid of what happens if they do not. A practice that could be moving on several fronts at once instead advances in single file, and the throughput of the whole team is capped by this self-imposed queue. The irony is sharp: the tool was adopted to let people work together, and the fear it induces makes them work one at a time.

The second cost is the retreat into private copies. An architect who does not trust the shared repository to protect their work will do the sensible thing and pull their work out of harm's way — take a copy, work on it where nobody can clobber it, and deal with reintegration later. This restores their peace of mind and destroys the point of a shared model. Now the team's work is scattered across private islands, the shared repository is perpetually out of date, and the dreaded reintegration is waiting at the end like a bill. The fear of a small, immediate overwrite drives people toward a large, deferred merge, which is a worse problem wearing a more comfortable disguise.

The third cost is the most insidious because it is a cost in things that never happen. It is the change not made. The tidy-up postponed. The correction left in place because fixing it would mean touching an area someone else is in, and it is not worth the risk. Over time a model maintained by frightened people accumulates a layer of small deferred improvements — the cruft that everyone can see and nobody dares to clear, because clearing it means editing shared ground while others are on it. The model degrades not through anyone's neglect but through everyone's caution. Each individual act of holding back is reasonable; the aggregate is a model that is worse than the sum of its maintainers would produce if they were not afraid.

The fourth cost is emotional and cultural, and it compounds the rest. A team that operates under a low hum of anxiety about damaging each other's work is not a team that collaborates generously. People become protective of their areas, reluctant to let others in, quietly territorial. The very behaviour a shared model is meant to encourage — many hands improving a common asset — is discouraged by the ambient risk. Collaboration curdles into a set of fiefdoms with careful borders, and the practice loses the easy, overlapping, mutually-improving way of working that makes a team more than a collection of individuals.

Why reassurance and process do not fix it

The usual responses to this fear treat the symptom rather than the cause, and so they do not work for long.

One response is to tell people not to worry — to insist that collisions are rare and that everyone should just edit freely. This asks people to override a fear that is grounded in real risk, and it does not survive the first time someone is burned after taking the advice. You cannot reassure away a danger that genuinely exists; you can only remove the danger.

Another response is process: locking, check-out regimes, a rule that you must claim an area before working in it. This does reduce the risk of overwriting, but it does so by formalising the serialisation that was already the problem. Now the taking-turns is official. You cannot work on a locked area, so you wait, or you ask the holder to release it, or you work somewhere else. The fear of overwriting has been converted into the certainty of waiting, which is calmer but not faster. Locking trades a probabilistic anxiety for a deterministic bottleneck, and for a busy team the bottleneck may cost more than the anxiety did.

A third response is heavy coordination — constant communication about who is doing what, standing agreements about who owns which packages, a running commentary in a chat channel. This can work, after a fashion, for a small and disciplined team, but it scales badly and it turns collaboration into an overhead. People spend their attention on staying out of each other's way rather than on the architecture. And it is fragile: one missed message, one person who forgets to announce what they are doing, and the collision the whole apparatus was meant to prevent happens anyway.

What all three responses share is that they accept the underlying danger — that one person's work can destroy another's — and try to route human behaviour around it. The only durable fix is to make the danger not exist, so that there is nothing left to route around.

Removing the danger rather than managing it

The reason the fear exists is that the shared model, in many arrangements, cannot faithfully combine two people's work. It can only hold one coherent state, so when two states arrive, one must give way to the other. Everything downstream — the caution, the serialisation, the private copies, the deferred changes — follows from that single limitation. Remove the limitation, and the whole edifice of fear-driven behaviour loses its foundation.

CelinQ removes it by never asking the shared model to choose one person's whole state over another's. Each architect edits their own local repository at full speed, and a background companion service detects each save and synchronises it with the shared workspace. The combining of everyone's work is done by the merge engine, CelinQ Fusion, and the way Fusion works is precisely what dissolves the fear.

Fusion merges at the level of individual model facts, not whole files or whole packages. This is the crux. When two architects work in the same package, or even on the same diagram, they are almost always changing different facts — different elements, different attributes, different relationships. Because Fusion reasons at that fine grain, it can combine both people's changes cleanly, keeping all of it, because there was never really a conflict at the level of facts even though there appeared to be one at the level of files. The overwhelming majority of the situations that used to trigger the fear were never genuine collisions at all; they only looked like collisions because the tool could not see below the level of the whole file. Once the engine can see the individual facts, most of the fear turns out to have been about a danger that, examined closely, was not there.

The merge is deterministic and reproducible, which matters more than it might first appear. It means the outcome of combining two people's work does not depend on timing, or luck, or who happened to save a moment sooner. Given the same set of changes, Fusion produces the same result every time. There is no race to win and no race to lose. The architect who saves second is in no more danger than the one who saved first, because Fusion is not choosing between them — it is combining them.

Deletions, which are the trickiest thing to get right in any merge and a common source of silent loss, are handled explicitly. When someone deletes a fact, Fusion records the deletion as a deliberate act using a tombstone, so the absence is understood as intentional rather than treated as an accident to be undone. This is what stops a deleted element from quietly reappearing because someone else's older copy still contained it, and equally what stops a still-wanted element from silently vanishing during a merge. The record of removal is as much a first-class fact as the record of creation.

What happens when two people really do collide

Honesty requires addressing the case that is a genuine conflict — where two architects really have changed the very same fact in incompatible ways, not merely worked in the same neighbourhood. This does happen, and any system that claimed otherwise would be untrustworthy. The difference is in what happens next.

A system built on last-write-wins resolves the genuine conflict by discarding one side, silently, and moving on. The loser finds out later, if they find out at all. CelinQ does the opposite. When Fusion encounters a true conflict, it does not resolve it by fiat and it does not hide it. It isolates the conflict and surfaces it for a human to settle, keeping both sides intact until someone with the judgement to decide has actually decided. Nobody's work is thrown away by a rule. The two intentions are held side by side, and a person chooses how they combine, which is the only party actually qualified to make that call.

This is the move that finally removes the fear rather than merely lowering it. The architect no longer has to worry that saving might silently destroy a colleague's work, because the system will not let that happen — the worst case is not a silent loss but a visible conflict that a human resolves deliberately. And a visible conflict, unlike a silent overwrite, is not something to be afraid of. It is just a small, occasional decision, made in the open, with all the information present. The dread was never really about doing the occasional bit of reconciliation; it was about doing damage without knowing. Take away the possibility of unknowing damage and the dread has nothing left to attach to.

What a practice does with the fear gone

It is worth dwelling on the positive change, because removing a silent tax frees up more than most people expect. When architects genuinely trust that their work cannot be silently clobbered and that their colleagues' work is equally safe from them, the defensive behaviours unwind one by one.

People stop serialising. They work in parallel because parallel work is now safe, and the throughput of the team rises to what its size should actually support rather than what its caution allowed. People stop retreating into private copies, because the shared workspace is now the comfortable place to work rather than the dangerous one, so the model stays current and the dreaded end-of-project reintegration simply does not accumulate. People stop deferring the small corrections, because touching shared ground while others are on it is no longer a gamble, so the model's quality stops silently eroding and starts quietly improving. And the culture relaxes: architects become willing to reach into each other's areas to help, because helping no longer risks harming. The practice recovers the generous, overlapping way of working that was the whole reason to share a model in the first place.

None of this requires the individual architect to change how they work. They continue to edit their own local repository, at full speed, online or offline, alongside Sparx Enterprise Architect exactly as before. The companion service synchronises in the background, adapting its rhythm to the connection, and Fusion combines everyone's work faithfully without anyone having to think about it. The complete, ordered history means that on the rare occasion something does need untangling, the team can see exactly who changed what and in what order, which turns a former source of anxiety into a matter of simply looking it up. The fear does not need to be managed with process and vigilance, because the thing it was afraid of no longer exists.

Why fine-grained merging is the whole game

It is worth pausing on why the level at which a merge operates matters so much, because it is the single technical choice from which everything else in this argument follows, and a skeptical architect is right to want it made concrete rather than asserted. Think about what a model actually is: not a monolithic document but a dense web of small, discrete assertions. This element exists. It has this name and this stereotype. It carries these attributes with these values. It sits in this package. It is connected to that element by a relationship of this kind, pointing this way. Each of these is a fact, and a model of any size is made of thousands upon thousands of them.

When a tool can only reason about the model as a whole file, it is blind to this structure. From its vantage point there is just the old file and the new file, and if two new files arrive built from the same old one, it has no way to see that they mostly agree and differ only in a few facts. All it can see is that they are two different files, so it must pick one. Every disagreement, however small and however easily reconciled, is escalated to a total contest between two entire states of the model, and total contests can only be settled by one side losing completely. This is the machinery that produces the silent overwrite, and it is also the machinery that produces the fear, because when the only possible outcome of a collision is total loss for one party, caution is the only sane response.

A tool that reasons at the level of individual facts sees the same situation entirely differently. It can look at two contributions and observe that they touch almost entirely separate sets of facts, combine those cleanly, and narrow any genuine disagreement down to the precise facts that actually conflict — which is usually a tiny fraction of what looked, at the file level, like a wholesale collision. The escalation from small disagreement to total contest simply does not occur, because the engine never had to treat the model as an indivisible lump in the first place. This is why fine-grained merging is not a mere refinement of the file-level approach but a different thing in kind. It changes the default outcome of two people working near each other from loss to combination, and once the default is combination, the fear has nothing to feed on.

A grounded takeaway

The fear of overwriting a colleague is one of those costs that a team learns to live with because it never quite crosses the threshold into a named problem. But live with it long enough and it shapes everything: the pace, the parallelism, the willingness to maintain the model well, and the generosity of the collaboration. You cannot argue a team out of this fear, and you cannot process your way around it, because the fear is a rational response to a real danger. The only thing that actually works is to remove the danger — to make it genuinely impossible for one person's save to silently destroy another's, to combine work faithfully at the level of individual facts, and to handle the rare true conflict in the open, with a human in charge, rather than in the dark. Do that, and designing stops being an act performed nervously around other people's work. It becomes what it was always supposed to be: a group of capable people improving a shared model together, without anyone looking over their shoulder. That is the working life CelinQ is built to make normal.