Changing Direction Early

A plan is a decision made with little knowledge. Sometimes the work itself shows that it was wrong — and then you face a choice: defend it or change it. This story is about that choice. It is deliberately kept general — no system, no people involved, no point in time.

Situation

The plan was to extend an existing system with additional features — an obvious, sensible path. You build on what is already there instead of starting over. The work began in that direction.

Initial assumptions

The assumption behind the plan was the usual one, and usually correct: extending is cheaper than rebuilding because you make use of what exists. As long as one feature fits with the next, that holds true. The plan was not careless; at the time it was made, it was the sensible choice.

Problem

As the work progressed, however, it became clear that every additional feature increased the complexity of the whole instead of fitting in. What was added didn't fit the existing model; it stretched it further, until the model started carrying things it was never meant to carry. The plan was not leading to a bigger system but to a more tangled one.

Root cause

The cause was not the plan itself but clinging to an assumption the work was in the middle of disproving. "Extending is cheaper" only holds as long as the new belongs with the existing. Here it didn't — it was standalone and was only being put into the same container out of habit. The mistake would have been to not see this yet and keep building because the plan said so.

Decision

We changed direction. Instead of forcing more features into the existing system, we split them out as standalone APIs — where they belonged. That meant discarding part of what had already been started and leaving the chosen path, even though it had felt like progress.

Implementation

The features that didn't belong in the existing model were separated out and designed as standalone interfaces, with clear boundaries to the existing system. The existing system stayed what it was; the new grew alongside it, not inside it. Breaking with the plan was the most expensive part — not technically, but because it meant giving up work already begun.

Trade-offs

Changing direction has a visible price: part of the work already done was wasted, and for a moment the switch looked like a step backward. Set against that was the invisible, larger price of carrying on — a system that would have become harder to understand with every feature. We would have decided differently if the new had genuinely belonged with the existing; then extending would have been right, and switching would have been nothing but expensive churn.

What we learned

Changing a plan as soon as the work disproves it is cheaper than defending it until it fails. The instinct to stick to the chosen path grows with every hour invested — and that is exactly what makes it dangerous: it rewards persistence where turning back is called for. The invested work is lost the moment the plan is wrong; adding to it only makes the loss bigger. The question is never how far you have already come, but whether the path is still right.

How this changed Batunet

Since then, we treat a plan as what it is: an early decision made with little knowledge, not a promise that has to be kept. When the work shows that a feature doesn't belong in the system, we split it out instead of forcing it in — and we count an early change of direction as a strength, not a failure. For us, turning back is not a defeat but a form of diligence.

Further reading

• Guide: Why software projects really fail — why decisions become irreversible before you understand enough.
• Opinion: Why premature abstraction creates complexity — clinging to a structure that no longer fits.
• Decision: Modular monolith vs. microservices — when something belongs in the system and when alongside it.
• Guide: Software that still runs in ten years — why changeability determines value.

It is grounded in the Batunet Engineering Method: build in small, reversible steps and decide once you know more — don't cling to the first plan.

The hours you have put into a wrong plan are lost the moment it is wrong. Adding to them only makes the loss bigger, not smaller.