Die seltsame Eigenschaft von Software

Es gibt etwas Merkwürdiges an Software.
Sie kann hervorragend funktionieren.
Und trotzdem schlecht gestaltet sein.

Bei den meisten Dingen merkt man schlechtes Design sofort.
Ein Stuhl ist unbequem.
Eine Tür verwirrt.
Ein Auto fährt sich seltsam.

Das Feedback kommt schnell.

Software ist geduldiger.
Sie trägt erstaunlich viel mit sich herum.
Vielleicht zu viel.

Funktionieren reicht erstaunlich weit

In der Softwarebranche sprechen wir gerne über Architektur.
Patterns.
Schichten.
Frameworks.
Best Practices.
Governance.

Die implizite Hoffnung lautet:

Wenn wir die richtigen Verfahren anwenden, entsteht gute Software.

Und oft entsteht tatsächlich funktionierende Software.

Das ist nur nicht dasselbe.

Illustration eines Hasen in einem übermäßig komplex konstruierten Schaukelstuhl, der trotz seiner aufwendigen Mechanik offensichtlich seinen Zweck erfüllt.

Wenn Verfahren zu Design werden

Vielleicht liegt genau darin eine Besonderheit unseres Handwerks.

Wenn wir nicht wissen,
wie wir ein Problem elegant lösen sollen,
bauen wir noch eine Schicht.

Ein Interface.
Eine Abstraktion.
Ein Framework.
Einen Service.

Das funktioniert erstaunlich oft.
Zumindest eine Zeit lang.

Software ist eine der wenigen Disziplinen,
in denen fehlendes Design
erstaunlich lange
durch Verfahren verborgen werden kann.

Die beruhigende Wirkung von Komplexität

Das Schwierige daran:

Komplexität wirkt erstaunlich professionell.

Mehr Infrastruktur.
Mehr Architektur.
Mehr Flexibilität.
Mehr Zukunftssicherheit.

Alles klingt vernünftig.
Alles lässt sich begründen.

Und genau deshalb entsteht daraus selten Unsinn.

Es entsteht etwas viel Gefährlicheres:

Das Gefühl,
gründlich gearbeitet zu haben.

Warum Software so geduldig ist

Die physikalische Welt ist ungeduldig.

Eine Brücke stürzt irgendwann ein.
Ein Stuhl wackelt.
Ein Auto fährt schlecht.

Software macht das nicht.

Sie trägt unnötige Struktur.
Jahrelang.
Manchmal jahrzehntelang.

Sie funktioniert einfach weiter.

Die verspätete Rechnung

Deshalb kommt das Feedback oft sehr spät.
Nicht nach einer Woche.
Nicht nach einem Release.

Manchmal erst nach Jahren.

Dann, wenn plötzlich jede Änderung länger dauert.
Wenn Spezialwissen unverzichtbar wird.
Wenn niemand mehr erklären kann,
warum eine bestimmte Schicht überhaupt existiert.

Oder wenn ein eigentlich kleines Feature
wochenlange Diskussionen auslöst.

Die Kosten waren die ganze Zeit da.

Sie standen nur in keinem Monitoring.

Eine Intuition für Komplexität

Mit der Zeit entwickelt man dafür eine Art Intuition.

Man schaut auf ein System und denkt:

Für dieses Problem wird hier erstaunlich viel Struktur benötigt.

Nicht:

Das ist falsch.

Sondern:

Das wirkt teuer.

Teuer für Verständnis.
Teuer für Veränderungen.
Teuer für alle,
die nach uns kommen.

Die eigentliche Designfrage

Vielleicht beginnt Design genau hier.

Nicht bei Patterns.
Nicht bei Frameworks.
Nicht bei Architekturdiagrammen.

Sondern bei der Frage:

Warum braucht dieses Problem eigentlich so viel Struktur?

Manchmal gibt es gute Gründe.
Oft aber auch nicht.

Das Problem blieb klein

Software kann erstaunlich lange
ohne gutes Design überleben.

Das unterscheidet sie
von fast allen anderen Ingenieursdisziplinen.

Vielleicht wird Design deshalb
so häufig unterschätzt.

Die Alternative funktioniert schließlich auch.
Lange genug.

Bis irgendwann niemand mehr versteht,
warum etwas so gebaut wurde.

Und dann stellt man fest:

Das Problem hat sich kaum verändert.

Nur die Lösung darum.