Erst zusammenfalten, dann optimieren

Wer Software entwickelt, kennt das: Eine neue Anforderung kommt hinzu, also baut man eine neue Funktion. Vielleicht braucht es eine neue Tabelle, ein paar Scripts und eine zusätzliche Maske. Alles funktioniert, der Kunde ist zufrieden.

Beim nächsten Mal passiert dasselbe.

So wachsen die Systeme. Nicht unbedingt, weil sie schlecht entwickelt werden, sondern weil jede neue Aufgabe zunächst als etwas Eigenständiges betrachtet wird.

Ich habe mir über die Jahre eine andere Arbeitsweise angewöhnt. Bevor ich etwas Neues baue, suche ich zuerst nach dem, was bereits vorhanden ist. Nicht nur nach wiederverwendbarem Code, sondern nach Gemeinsamkeiten, die vielleicht noch gar nicht offensichtlich sind.

Ich nenne das Zusammenfalten.

Was ich unter Zusammenfalten verstehe

Eine Offerte enthält Positionen. Eine Rechnung auch. Ein Auftrag, ein Lieferschein und eine Bestellung ebenfalls.

Man könnte für jedes dieser Dokumente eigene Tabellen, eigene Scripts und eigene Funktionen entwickeln. Schliesslich haben sie unterschiedliche Aufgaben und teilweise unterschiedliche Anforderungen.

Oder man erkennt, dass sie im Kern dasselbe tun: Sie verwalten Positionen.

In meinem ERP gibt es deshalb eine gemeinsame Struktur für solche Positionen. Was sich unterscheidet, wird über Daten und Regeln gesteuert, statt dieselbe Logik mehrfach zu programmieren.

Das klingt zunächst unspektakulär.

Aber jetzt kommt eine neue Anforderung: Positionen sollen zusätzliche Informationen enthalten, anders berechnet oder auf eine neue Weise verarbeitet werden.

In einem System mit fünf getrennten Strukturen muss ich fünf Stellen prüfen und möglicherweise fünfmal eingreifen. In meinem ERP genügt dafür ein einziger Ort. Und aus den ursprünglich fünf Anwendungsfällen sind inzwischen dreizehn geworden, die alle dieselbe Struktur nutzen. Jede neue Funktion und jede Verbesserung kommt damit automatisch allen dreizehn zugute.

Und das gilt nicht nur heute, sondern bei jeder zukünftigen Erweiterung.

Die eigentliche Ersparnis entsteht nicht beim Zusammenlegen. Sie entsteht in all den Jahren danach.

Der Unterschied zwischen Optimieren und Zusammenfalten

Optimieren bedeutet, etwas Bestehendes besser zu machen. Eine Abfrage wird schneller, ein Script kürzer, ein Ablauf einfacher.

Das ist wichtig. Aber die Struktur bleibt im Wesentlichen bestehen.

Zusammenfalten setzt früher an. Ich frage mich, ob es diesen Ablauf, diese Tabelle oder diese Unterscheidung überhaupt braucht.

Wenn zwei Funktionen im Kern dieselbe Aufgabe erfüllen, versuche ich daraus eine zu machen. Die Unterschiede werden zu Eigenschaften oder Regeln.

Danach kann ich die verbleibende Funktion optimieren.

Die Reihenfolge ist entscheidend.

Wer zuerst fünf verschiedene Abläufe optimiert und sie anschliessend zusammenlegt, hat einen grossen Teil seiner Arbeit umsonst gemacht.

Wer zuerst zusammenfaltet, optimiert nur noch einmal. Und alle fünf Anwendungsfälle profitieren davon.

Die Wirkung wächst mit jedem Jahr exponentiell

Am Anfang macht diese Arbeitsweise kaum einen sichtbaren Unterschied.

Ob eine Anwendung zehn oder zwölf Tabellen hat, interessiert niemanden. Vielleicht braucht das Zusammenfalten sogar mehr Zeit, weil ich die Gemeinsamkeiten zuerst verstehen muss.

Nach fünf Jahren sieht es anders aus.

Jede neue Funktion baut auf den bisherigen Entscheidungen auf. Wo andere Systeme zusätzliche Varianten und Sonderfälle entwickeln, kann ich bestehende Bausteine erweitern.

Nach fünfzehn Jahren ist der Unterschied gewaltig.

Denn jede Struktur, die ich nicht geschaffen habe, musste ich später auch nicht dokumentieren, warten, testen, erweitern oder mit anderen Strukturen synchronisieren.

Und jede Verbesserung an einem gemeinsamen Baustein kommt allen Funktionen zugute, die ihn verwenden.

Das ist kein einmaliger Spareffekt. Es ist ein Effekt, der sich über Jahrzehnte gegenseitig verstärkt.

Komplexität, die gar nicht erst entsteht, muss später auch niemand beherrschen.

Ein Beispiel aus diesem Herbst

Vor Kurzem habe ich den Mailversand meines ERP überarbeitet.

Über die Jahre waren verschiedene Versandwege entstanden: für Briefe, Aufträge, Rechnungen, Kursteilnehmer, Lizenzen und Systemmeldungen. Jeder funktionierte. Jeder hatte aber auch seine eigene Geschichte und seine Besonderheiten.

Ich hätte diese Abläufe einzeln verbessern können.

Stattdessen habe ich sie zusammengefaltet.

Heute gibt es eine gemeinsame Versandkette. Ob eine Rechnung, ein Serienbrief oder eine Systemmeldung verschickt wird, entscheidet die Konfiguration.

Auch die Anhänge werden nicht mehr über verschiedene Speziallösungen zusammengestellt. Ein gemeinsamer Baustein erledigt das.

Dadurch sind nicht nur Scripts und Sonderfälle verschwunden. Neue Funktionen wie Entwürfe, Versandgrenzen oder ein Sendestatus stehen automatisch allen Versandarten zur Verfügung.

Früher hätte jede dieser Erweiterungen mehrere Eingriffe erfordert. Heute ist es einer.

Das gleiche Prinzip steckt inzwischen auch hinter meinem Publikationssystem. Webseite, Blog, Newsletter und Kundeninformationen sind keine voneinander isolierten Werkzeuge. Sie verwenden gemeinsame Inhalte und Bausteine, die je nach Kanal unterschiedlich ausgegeben werden.

Ein Beitrag kann dadurch auf mehreren Kanälen erscheinen, ohne dass ich ihn mehrfach verwalten muss.

Warum das nicht immer einfach ist

Zusammenfalten verlangt mehr als das Erkennen ähnlicher Funktionen.

Zwei Abläufe können auf den ersten Blick identisch aussehen und im Detail völlig unterschiedliche Regeln haben. Wer sie vorschnell vereinheitlicht, verschiebt die Komplexität nur. Statt zweier sauberer Lösungen entsteht dann eine gemeinsame Funktion voller Ausnahmen.

Damit wäre nichts gewonnen.

Ich muss deshalb die Abläufe und ihre Zusammenhänge verstehen. Von den Daten über die Geschäftsregeln bis zu den einzelnen Scriptschritten.

Erst wenn die Gemeinsamkeit wirklich trägt, lohnt sich die Zusammenlegung.

Das ist auch einer der Gründe, weshalb ich mein ERP über so viele Jahre praktisch im Alleingang entwickeln konnte. Ich kenne nicht nur die einzelnen Module, sondern auch die Verbindungen dazwischen. Dadurch sehe ich Gemeinsamkeiten, die bei einer Aufteilung auf verschiedene Entwickler oder Teams leicht übersehen werden.

Natürlich hat das seinen Preis. Viel Wissen steckt zunächst in meinem Kopf. Deshalb investiere ich seit Jahren in konsequente Benennung, klare Strukturen und Dokumentation.

Denn ein gutes System sollte auch ohne seinen ursprünglichen Entwickler verständlich bleiben.

Weniger Struktur, mehr Möglichkeiten

Eine gemeinsame Struktur bedeutet nicht, dass alle Anwendungsfälle gleich sein müssen.

Im Gegenteil. Wenn das Fundament stimmt, lassen sich Unterschiede oft als Daten, Eigenschaften und Regeln beschreiben, ohne dafür jedes Mal neue Programmteile zu bauen.

Das macht ein System nicht nur kleiner, sondern auch beweglicher.

Es gibt weniger Stellen, an denen Fehler entstehen können. Änderungen wirken konsistenter. Neue Funktionen können auf bereits vorhandenen Fähigkeiten aufbauen. Und der Aufwand für Tests, Dokumentation und Support bleibt überschaubarer.

Natürlich muss ein gemeinsam verwendeter Baustein besonders sorgfältig getestet werden. Ein Fehler kann viele Funktionen gleichzeitig betreffen. Das Zusammenfalten beseitigt nicht jede Komplexität und ersetzt keine Qualitätskontrolle.

Aber es hilft mir, die Komplexität dort zu halten, wo sie hingehört: in den tatsächlichen Anforderungen, statt in immer neuen technischen Konstruktionen.

Heute kommt noch etwas hinzu. Klare, konsistente Strukturen sind auch für künstliche Intelligenz leichter zu verstehen. Eine KI muss nicht fünf unterschiedliche Lösungen lernen, wenn dieselbe Regel überall gilt.

Was ich ursprünglich gebaut habe, um selbst den Überblick zu behalten, wird damit zur Grundlage für eine neue Art der Softwareentwicklung.

Eine Frage, die mich seit Jahren begleitet

Wenn ich heute eine neue Funktion plane, frage ich nicht zuerst, wie ich sie möglichst schnell programmieren kann.

Ich frage mich, was davon eigentlich schon vorhanden ist. Was wirklich neu ist. Und ob sich durch die neue Anforderung vielleicht sogar etwas Bestehendes vereinfachen lässt.

Manchmal ist die Antwort eine neue Funktion. Manchmal eine zusätzliche Tabelle.

Und manchmal verschwinden am Ende mehr Scripts, Tabellen und Sonderfälle, als neu dazukommen.

Das sind für mich die erfreulichsten Entwicklungen.

Denn die beste Optimierung ist manchmal die Funktion, die man gar nicht mehr braucht.