Hast du schon einmal von einem Softwareprojekt gehört, das die Frist verpasst hat, voller Fehler war und letztendlich viel mehr gekostet hat als geschätzt?
Es gibt einen Grund, warum so viele Softwareprojekte das Budget überschreiten, verspätet geliefert werden oder die Bedürfnisse der Endbenutzer nicht erfüllen – und es ist wahrscheinlich nicht das, was du denkst.
Bauingenieurwesen
Viele Entwicklerteams nähern sich der Softwareentwicklung mit Praktiken, die aus dem Bauingenieurwesen entlehnt sind.
Es könnte dich überraschen, aber diese Praktiken des Bauingenieurwesens wurden bereits im 19. Jahrhundert entwickelt – vor 1900.
Das bedeutet im Wesentlichen, dass viele Softwareprodukte mit über 100 Jahre alten Ingenieurspraktiken entwickelt werden!
Wir hatten damals keine Software – tatsächlich hatten wir nicht einmal Computer. Am Ende des 19. Jahrhunderts waren wir noch damit beschäftigt, uns an Glühbirnen zu gewöhnen.
Praktiken des Bauingenieurwesens eignen sich gut für den Bau von Brücken und Wolkenkratzern. Hier ist es sinnvoll, viel Zeit und Mühe in die Planung, das Erstellen von Blaupausen und sogar in teure formale Abnahmen zu investieren, bevor die nächste Entwicklungsphase beginnt.
Und warum ist das so?
Im Bauingenieurwesen können Fehler sich als wirklich, wirklich teuer herausstellen.
Beim Bau eines Hauses ist es sinnvoll, mit dem Fundament zu beginnen, dann Etage für Etage aufzubauen und schließlich alle Elektro- und Sanitärinstallationen einzubauen.
Was bei Gebäuden gut funktioniert, versagt bei Software.
Software ist von Natur aus grundlegend anders als Dinge, die wir bauen können.
Sobald wir ein Haus gebaut haben, werden Veränderungen extrem schwierig, wenn nicht sogar unmöglich.
Software hingegen ist … nun ja, flexibel. Dinge ändern sich ständig. Es ist eher wie ein lebendiges Wesen.
Anforderungen werden sich beispielsweise im Verlauf eines Softwareprojekts ändern. Es ist unmöglich, alle Softwareanforderungen im Voraus festzulegen und sie richtig zu erfassen.
SOFTware zu bauen ist HART
Der Versuch Software wie ein Gebäude bauen zu wollen ist eine törichte Unternehmung.
Und deshalb vergleiche ich Software gerne mit Pflanzen.
Wir können einen Baum nicht einfach bauen!
Wir müssen damit beginnen, ein Setzling zu pflanzen. Wir müssen ihn gießen. Und wenn wir uns nicht um ihn kümmern, wird er absterben oder wild wachsen. Deshalb müssen wir ihn von Zeit zu Zeit beschneiden.
Im Laufe der Zeit wird der Setzling zu einem Spross, dann zu einem kleinen Baum und schließlich wird er sich in eine mächtige Eiche verwandeln.
Wir können ein Haus nicht ohne Fundament bauen oder in einem Gebäude leben oder arbeiten, bevor es fertiggestellt ist. Ein Baum hingegen kann die Luft entkohlen oder Schatten spenden, lange bevor er sich in eine mächtige Eiche verwandelt.
Mit Software ist es ähnlich. Software verschlechtert sich im Laufe der Zeit, wenn wir nicht handeln. Wir müssen sie warten, um sie am Leben zu erhalten.
Wir müssen Open-Source-Bibliotheken aktualisieren, um Sicherheitslücken zu schließen. Wenn wir Funktionen hinzufügen und die Komplexität zunimmt, müssen wir unseren Code vereinfachen und aufräumen (auch bekannt als Refactoring). Und wir müssen Funktionen basierend auf dem Feedback der Endnutzer und sich entwickelnden gesetzlichen Anforderungen ändern.
Wenn wir das nicht tun, wird das Softwareprodukt sterben.
Ein Softwareprodukt, das das Problem des Endnutzers nicht löst, wird nicht verwendet und wird keine Einnahmen generieren, um die Entwicklungs- und Wartungskosten zu decken.
Wenn die Software nicht regelmäßig aktualisiert wird, könnte sie aus App-Stores entfernt oder von einer rechtlichen Instanz abgeschaltet werden.
Und wenn der Code nicht kontinuierlich überarbeitet wird, wird die Entwicklungsgeschwindigkeit für das Hinzufügen von Funktionen oder das Beheben von Problemen langsamer (was bedeutet, dass es zunehmend teurer wird). Schließlich werden die Entwickler darum bitten die Codebasis komplett neu zu schreiben oder das Unternehmen verlassen. Dann wird die Entwicklung des Produkts zum Stillstand kommen.
Die Erstellung von Software erfordert einen anderen Ansatz.
Die Codebasis muss anpassbar sein und der Entwicklungsansatz selbst muss berücksichtigen, dass sich die Software im Laufe der Zeit ändern wird.
Die Agile-Bewegung in den 90er Jahren erkannte dies an, indem sie neue Prinzipien wie Emergent Design und Entwicklungsmethoden wie Test-First-Programming einführte. Die DevOps-Bewegung in den 2010er Jahren baute darauf auf, indem sie Praktiken entwickelte, die sich wiederholende und fehleranfällige operationale Aufgaben automatisieren.
Mit Agile und DevOps entwickeln wir Softwareprodukte inkrementell.
In der Regel beginnen wir mit den wichtigsten Funktionen und reservieren weniger wichtige Details für später. Das stellt sicher, dass es von Anfang an während des Entwicklungsprozesses etwas von Wert für die Endbenutzer gibt.
Wie der Setzling, der bereits die Luft entkohlen kann, oder der junge Baum, der bereits Schatten spenden kann.
Jede Produkt-Verbesserung kann unseren Endnutzern präsentiert werden. Kurze Feedback-Zyklen führen letztendlich zu höherer Qualität und verringern das Risiko, das falsche Produkt zu entwickeln.
Im Laufe der Zeit wird die Software zu einer ausgeklügelten Lösung heranwachsen, die alle wesentlichen Funktionen und vielleicht sogar einige optionale Funktionen enthält, die nicht jeden Tag benötigt werden.
Leider haben viele Unternehmen bis heute die Prinzipien und Praktiken von Agile oder DevOps noch nicht übernommen. Einige geben vor, agil zu sein, aber wenn man genauer hinsieht, merkt man, dass sie es nur vortäuschen. Ihre Projekte scheitern wie zuvor. Sie überschreiten das Budget, sind verspätet und die Qualität ist schlecht. Aber das ist eine andere Geschichte.
Was hältst du von der Pflanzenmetapher, die ich für Software verwende? Schick mir eine Nachricht und lass es mich wissen – ich lese alle E-Mails!
Bis demnächst
David