Wir bauen Software aber das macht sie noch lange nicht zum Bauprojekt.

Wir sprechen von Softwarearchitektur, Fundamenten, Baustellen, technischen Schulden und natürlich davon, Software zu bauen. Die Sprache der Softwareentwicklung ist voller Begriffe aus dem Bauwesen.

Diese Begriffe sind hilfreich. Sie machen abstrakte Konzepte greifbar und ermöglichen es uns, komplexe technische Zusammenhänge zu beschreiben. Gleichzeitig transportieren sie jedoch eine Annahme, die wir selten hinterfragen.

Wenn wir etwas bauen, dann muss es doch einem Bauprojekt ähneln?!

Genau an dieser Stelle beginnt meiner Meinung nach der Denkfehler

Denn Sprache prägt unser Denken. Wer über Software als Bauwerk spricht, übernimmt häufig unbewusst auch die Vorstellungen, die mit einem Bauprojekt verbunden sind: detaillierte Planung, klar definierte Anforderungen, vorhersehbare Ergebnisse und die Erwartung, dass das Endprodukt bereits zu Beginn weitgehend bekannt sein muss.

Für Häuser, Brücken oder Fabrikhallen kann diese Annahme funktionieren. Für Software trägt sie nur begrenzt, weil dort nicht nur umgesetzt, sondern während der Entwicklung überhaupt erst verstanden wird, was sinnvoll ist.

Denn obwohl wir Software bauen, verhält sie sich nicht wie ein Bauwerk. Sie besteht nicht aus Beton, Stahl und physikalischen Gesetzmäßigkeiten, sondern aus Wissen, Annahmen, Fachlichkeit und menschlichen Entscheidungen. Während ein Bauprojekt überwiegend die Umsetzung eines bekannten Ziels ist, besteht Softwareentwicklung häufig darin, das eigentliche Ziel überhaupt erst zu verstehen.

Genau deshalb macht das Wort „bauen“ Software noch lange nicht zu einem Bauprojekt.

Die Herkunft unserer Denkmodelle

Um zu verstehen, warum dieses Missverständnis so hartnäckig ist, lohnt sich ein Blick in die Geschichte des Projektmanagements. Viele Methoden, Werkzeuge und Planungsansätze, die wir heute als selbstverständlich betrachten, entstanden ursprünglich in Bereichen wie dem Bauwesen, dem Militär oder der industriellen Fertigung. Dort waren sie nicht nur sinnvoll, sondern oft zwingend notwendig.

Wer eine Brücke baut, muss Materialien beschaffen, Gewerke koordinieren, Abhängigkeiten verstehen und Risiken minimieren. Fehler können teuer werden oder sogar Menschenleben kosten. Planung ist in solchen Umgebungen kein bürokratischer Selbstzweck, sondern eine Grundvoraussetzung für Erfolg.

Dabei bewegen sich Bauprojekte in einer vergleichsweise stabilen Welt. Natürlich gibt es Überraschungen, Lieferengpässe oder Berechnungsfehler. Die grundlegende Aufgabe bleibt jedoch meist unverändert. Am Anfang soll ein Fluss überquert werden und am Ende ebenfalls. Die Anforderungen verändern sich während der Umsetzung selten grundlegend.

Ein Stahlträger wird nicht plötzlich beschließen, seine Anforderungen nach dem dritten Sprint anzupassen. Beton veröffentlicht keine neue Version und die Schwerkraft liefert erfreulicherweise nur sehr selten Breaking Changes.

Das bedeutet nicht, dass Bauprojekte einfach wären. Sie sind komplex, teuer und oft hochgradig risikobehaftet. Dennoch bewegen sie sich in einem Umfeld, in dem die Gesetzmäßigkeiten bekannt und die Ziele meist stabil sind.

Warum Software anders funktioniert

Softwareprojekte folgen einer anderen Logik. Sie entstehen selten durch die reine Umsetzung bekannter Anforderungen. Viel häufiger sind sie ein Prozess des Lernens und Entdeckens.

Zu Beginn eines Projekts glaubt der Kunde zu wissen, was er benötigt. Die Fachabteilung glaubt zu wissen, was die Anwender brauchen, und das Entwicklungsteam glaubt zu wissen, wie die passende Lösung aussehen könnte. Nach einigen Monaten stellen jedoch alle Beteiligten fest, dass ihre ursprünglichen Annahmen nur teilweise richtig waren.

Das ist kein Zeichen schlechter Arbeit, sondern die normale Konsequenz komplexer Problemstellungen. Die eigentliche Herausforderung besteht häufig nicht darin, bekannte Anforderungen umzusetzen, sondern herauszufinden, welche Anforderungen überhaupt sinnvoll sind.

Während im Bauwesen der Lösungsraum oft bereits weitgehend bekannt ist, wird er in Softwareprojekten erst während der Arbeit sichtbar.

Neue regulatorische Anforderungen entstehen. Nutzer verhalten sich anders als erwartet. Geschäftsmodelle ändern sich. Märkte entwickeln sich weiter. Technologische Möglichkeiten eröffnen neue Optionen. All diese Erkenntnisse fließen während der Entwicklung in das Produkt ein.

Softwareentwicklung ist deshalb nicht nur Umsetzung. Sie ist kontinuierliche Erkenntnisgewinnung.

Man könnte sagen: Softwareentwicklung lebt dauerhaft in einer Situation, die an Platons Höhlengleichnis erinnert. Wir betrachten zunächst nur Schatten an der Wand, also Annahmen, Modelle, Anforderungen, Erwartungen und vermeintliche Gewissheiten. Erst wenn wir arbeiten, bauen, testen, ausliefern und Feedback erhalten, treten wir ein Stück aus der Höhle heraus und erkennen, dass die Wirklichkeit komplexer ist als das Bild, das wir uns zuvor von ihr gemacht haben.

Der entscheidende Unterschied ist nur: In der Softwareentwicklung passiert dieser Moment nicht einmalig. Wir treten nicht aus der Höhle, erkennen die Wahrheit und sind danach fertig. Wir treten immer wieder heraus, sehen mehr, korrigieren unser Bild und stellen fest, dass auch die nächste Erkenntnis wieder nur ein Zwischenstand ist.

"Softwareentwicklung ist Erkenntnisgewinnung im Dauerloop."

Das große Missverständnis

Trotzdem behandeln viele Organisationen Softwareentwicklung bis heute wie einen Produktionsprozess. Zunächst wird analysiert, anschließend geplant, danach spezifiziert und schließlich umgesetzt. Die zugrunde liegende Annahme lautet, dass das gewünschte Ergebnis bereits zu Beginn ausreichend bekannt ist und lediglich effizient umgesetzt werden muss.

Genau an diesem Punkt kollidiert das Modell mit der Realität.

Komplexe Softwaresysteme sind keine Produktionsaufgabe. Sie sind Erkenntnisarbeit.

Natürlich gibt es Projekte mit klaren Anforderungen und überschaubaren Risiken. Doch je innovativer, komplexer oder fachlich anspruchsvoller eine Lösung wird, desto stärker verschiebt sich der Schwerpunkt von der Umsetzung hin zum Lernen.

Viele Projektpläne scheitern deshalb nicht an schlechter Planung. Sie scheitern an der Annahme, dass zu Projektbeginn bereits bekannt war, was am Ende tatsächlich benötigt wird.

Software ist ein Lernprozess, der so tut, als wäre er ein Bauprojekt

Vielleicht beschreibt dieser Satz das Problem besser als jede Methodendiskussion.

Wir erstellen umfangreiche Projektpläne, schätzen Aufwände, definieren Meilensteine und produzieren Dokumentationen, während gleichzeitig alle Beteiligten wissen, dass wesentliche Erkenntnisse erst während der Entwicklung entstehen werden. Wir simulieren Vorhersagbarkeit in einem Umfeld, das von Unsicherheit, Lernen und Anpassung geprägt ist.

Dabei handelt es sich keineswegs um individuelles Versagen. Vielmehr folgen wir Denkmustern, die über Jahrzehnte erfolgreich in anderen Branchen funktioniert haben. Das Problem entsteht erst dann, wenn wir vergessen, dass Software andere Eigenschaften besitzt als Beton, Stahl oder Maschinen.

Die Sehnsucht nach Kontrolle

Interessanterweise verstärkt sich dieses Muster oft mit zunehmender Unsicherheit. Je komplexer ein Projekt wird, desto größer wird häufig der Wunsch nach zusätzlicher Kontrolle. Es entstehen weitere Gremien, umfangreichere Reportings, detailliertere Statusberichte und immer größere Planungsartefakte.

Doch zusätzliche Planung reduziert Komplexität nicht automatisch. Sie kann sogar das Gegenteil bewirken, indem sie eine Illusion von Sicherheit erzeugt. Ein Gantt-Chart mit mehreren hundert Zeilen macht ein komplexes Projekt nicht einfacher. Es macht lediglich die Unsicherheit weniger sichtbar.

Die Realität bleibt davon unbeeindruckt denn Komplexität liest keine Projektpläne.

Was wir vom Bauwesen tatsächlich lernen können

Die Ironie dieser Diskussion besteht darin, dass gute Bauprojekte oft deutlich flexibler sind, als viele Menschen vermuten. Erfahrene Bauleiter reagieren kontinuierlich auf neue Erkenntnisse, Architekten passen Lösungen an geänderte Rahmenbedingungen an und Handwerker wissen sehr genau, dass kein Plan die Realität vollständig abbilden kann.

Vielleicht liegt das Problem also nicht darin, dass wir vom Bauwesen gelernt haben. Vielleicht liegt das Problem darin, dass wir vor allem dessen Planungsartefakte übernommen haben, nicht aber dessen Pragmatismus im Umgang mit Veränderungen.

Denn kein erfahrener Bauleiter würde behaupten, dass ein Plan wichtiger ist als die Realität auf der Baustelle.

Warum tun wir das dann so oft in Softwareprojekten?

Mein Fazit

Softwareentwicklung ist kein Fertigungsprozess und nur selten ein klassisches Bauprojekt. Sie ist in erster Linie ein Erkenntnisprozess, bei dem Wissen erst während der Arbeit oder der Testphase entsteht.

Wer diese Realität akzeptiert, wird nicht weniger professionell planen. Im Gegenteil: Planung wird zu einem Werkzeug, um Orientierung zu schaffen, anstatt die Zukunft vorhersagen zu wollen.

Der Unterschied mag klein erscheinen, verändert aber die Art, wie Projekte geführt werden, grundlegend.

"Denn die meisten Projekte scheitern nicht daran, dass zu wenig geplant wurde. Sie scheitern daran, dass man glaubte, bereits alles zu wissen."