Früh die Richtung ändern

Ein Plan ist eine Entscheidung, die man mit wenig Wissen getroffen hat. Manchmal zeigt die Arbeit selbst, dass er falsch war — und dann steht man vor der Wahl, ihn zu verteidigen oder ihn zu ändern. Diese Geschichte handelt von dieser Wahl. Sie ist bewusst allgemein gehalten — ohne System, ohne Beteiligte, ohne Zeitpunkt.

Situation

Der Plan war, ein bestehendes System um weitere Funktionen zu erweitern — ein naheliegender, vernünftiger Weg. Man baut, worauf schon etwas steht, statt neu anzusetzen. Die Arbeit begann in diese Richtung.

Ausgangsannahmen

Die Annahme hinter dem Plan war die übliche und meist richtige: Erweitern ist billiger als Neubauen, weil man das Vorhandene nutzt. Solange eine Funktion zur nächsten passt, stimmt das auch. Der Plan war nicht leichtfertig; er war zum Zeitpunkt seiner Entstehung die vernünftige Wahl.

Problem

Während der Arbeit wurde jedoch sichtbar, dass jede weitere Funktion die Komplexität des Ganzen erhöhte, statt sich einzufügen. Was hinzukam, passte nicht ins bestehende Modell, sondern spannte es weiter, bis es zu tragen begann, was es nicht tragen sollte. Der Plan führte nicht zu einem größeren, sondern zu einem verworreneren System.

Ursache

Die Ursache war nicht der Plan selbst, sondern das Festhalten an einer Annahme, die die Arbeit gerade widerlegte. „Erweitern ist billiger" gilt nur, solange das Neue zum Bestehenden gehört. Hier gehörte es nicht dazu — es war eigenständig und wurde nur aus Gewohnheit in denselben Behälter gelegt. Der Fehler wäre gewesen, das noch nicht zu sehen und weiterzubauen, weil es der Plan so vorsah.

Entscheidung

Die Richtung wurde geändert. Statt weitere Funktionen in das bestehende System zu drücken, wurden sie als eigenständige APIs herausgelöst — dort, wo sie hingehörten. Das hieß, einen Teil des schon Begonnenen zu verwerfen und den eingeschlagenen Weg zu verlassen, obwohl er sich nach Fortschritt angefühlt hatte.

Umsetzung

Die Funktionen, die nicht ins bestehende Modell gehörten, wurden herausgetrennt und als eigenständige Schnittstellen entworfen, mit klaren Grenzen zum bisherigen System. Das Bestehende blieb, was es war; das Neue wuchs daneben, nicht darin. Der Bruch mit dem Plan war der teuerste Teil — nicht technisch, sondern weil man Begonnenes aufgab.

Trade-offs

Die Richtung zu ändern hat einen sichtbaren Preis: Ein Teil der bereits geleisteten Arbeit war umsonst, und der Wechsel sah kurz nach Rückschritt aus. Dem stand der unsichtbare, größere Preis des Weitermachens gegenüber — ein System, das mit jeder Funktion schwerer zu verstehen geworden wäre. Anders hätten wir entschieden, wenn das Neue wirklich zum Bestehenden gehört hätte; dann wäre Erweitern richtig gewesen und der Wechsel nur teure Unruhe.

Was wir gelernt haben

Einen Plan zu ändern, sobald die Arbeit ihn widerlegt, ist billiger, als ihn zu verteidigen, bis er scheitert. Der Instinkt, am eingeschlagenen Weg festzuhalten, wächst mit jeder investierten Stunde — und genau deshalb ist er gefährlich: Er belohnt das Beharren dort, wo Umkehren geboten wäre. Die investierte Arbeit ist verloren, sobald der Plan falsch ist; sie weiter zu mehren macht den Verlust nur größer. Die Frage ist nie, wie viel man schon gegangen ist, sondern ob der Weg noch stimmt.

Wie das Batunet verändert hat

Seither behandeln wir den Plan als das, was er ist: eine frühe Entscheidung unter wenig Wissen, nicht ein Versprechen, das man einhalten muss. Wenn die Arbeit zeigt, dass eine Funktion nicht ins System gehört, lösen wir sie heraus, statt sie hineinzuzwingen — und werten den frühen Richtungswechsel als Stärke, nicht als Versäumnis. Umkehren ist bei uns keine Niederlage, sondern eine Form von Sorgfalt.

Weiterführend

• Guide: Warum Softwareprojekte wirklich scheitern — warum Entscheidungen unumkehrbar werden, bevor man genug versteht.
• Opinion: Warum vorzeitige Abstraktion Komplexität schafft — festhalten an einer Struktur, die nicht mehr passt.
• Decision: Modularer Monolith vs. Microservices — wann etwas ins System gehört und wann daneben.
• Guide: Software, die in zehn Jahren noch läuft — warum Änderbarkeit über den Wert entscheidet.

Grundlage ist die Batunet Engineering Method: in kleinen, umkehrbaren Schritten bauen und entscheiden, wenn man mehr weiß — nicht am ersten Plan festhalten.

Die Stunden, die man in einen falschen Plan gesteckt hat, sind verloren, sobald er falsch ist. Sie zu vermehren macht den Verlust nur größer, nicht kleiner.