Die Mythen der Softwareentwicklung
Falsch gedacht! Rund um die Softwareentwicklung haben sich viele Denkmodelle, Metaphern und gedankliche Haltungen etabliert. Einige davon sind richtig, andere wiederum nicht. Im Folgenden wollen wir uns einige Modelle anschauen, die wir bei der Biberei nutzen und wie sie sich auf unser Verständnis von Software und Softwareentwicklung auswirken.
Die Auseinandersetzung mit diesen Modellen fördert das Verständnis von Softwareentwicklung. Die Denkansätze die ich im Folgenden beschreibe, sind als Kondensat meiner Erfahrungen in der Softwareentwicklung zu verstehen und sollen versuchen diese Erfahrungen weiterzugeben.
Wir werden dabei probieren folgende Fragen zu beantworten:
Augen auf und bereit zum Reset! Machen wir uns daran unserer Gedanken neu zu sortieren.
Wenn wir an Softwareentwicklung denken, haben wir oft das Bild einer Ingenieurs-artigen Arbeit im Kopf. Der Ingenieur benutzt eine Software um Konstruktionszeichnungen anzufertigen oder Berechnungen anzustellen. Dabei greift er auf einen Rahmen an physikalischen Gesetzmäßigkeiten zurück, um sein Problem zu lösen. Er greift dabei auf lange bewährte Praktiken zurück und kann einen Bezug zwischen Ursache und Wirkung herstellen. Wenn das Material nicht genug Gewicht oder Hitze aushält, dann wird es beschädigt.
Genau diese Beziehung zwischen Ursache und Wirkung ist dem Softwareentwickler allerdings oft erst im Nachhinein bekannt. Wir kennen alle die lästigen Bugs - die Software funktioniert nicht wie wir es erwarten. Der Ingenieur arbeitet also an einem komplizierten Problem, bei dem er das Problem kennt und lösen kann (wenn auch mit vielen komplizierten Schritten). Der Softwareentwickler hingegen, sieht sich einem komplex Problem gegenüber. Das Verständnis, dass ein Bug unter einer bestimmten Bedingung auftreten kann wird erst geschaffen, wenn er aufgetreten ist. Wir sehen einen Vergleich zwischen komplizierten und komplexen Problemen in der Grafik.
Wir sehen hier die Beziehung zwischen Ursache und Wirkung in Form von Pfeilen dargestellt: Wann A (Pfeilanfang) dann folgt daraus B (Pfeilspitze). Die Umkehrung der Beziehungen bei komplexen Problemen bewirkt also eine gewisse Unsicherheit. Wir wissen also beim Release der Software nicht sicher, ob sie funktioniert bzw. das Problem löst für das sie geschrieben wurde. Daraus folgt also auch der Umstand, dass Software (fast) nie fertig ist.
Hoch-skalierende Systeme mit hunderten von Komponenten können sogar in den Bereich der chaotischen Probleme übergehen, bei dem wir gar nicht mehr nachvollziehen können, ob es sich bei einem Phänomen um Ursache oder Wirkung handel. Diese Art von Problemen wollen wir aber an dieser Stelle bewusst vernachlässigen. Es gibt ganze Disziplinen wie zum Beispiel Chaos Engineering, welche sich der Beherrschbarkeit dieser Probleme widmen.
Aber nun zurück zu der Eingangs formulierten Behauptung: Softwareentwickler designen digitale Lösungen. Wir haben also gesehen, dass sich Softwareentwicklung mit komplexen Problemen beschäftigt. Die Metapher vom Fließband, an dem Software - in Form von Codezeilen - von Entwicklern hergestellt wird, ist obsolet. Solange wir an Software arbeiten, haben wir das Problem noch nicht vollständig durchdrungen. Wir können also gar nicht wissen, wie das fertige digital Produkt aussehen wird. Daraus folgt, dass der Prozess der Softwareentwicklung eher dem des Designs entspricht. Es ist ein kreativer Prozess, der das Produkt formt und dabei maßgeblich auf kontinuierliches Feedback angewiesen ist. Dieses Feedback kennen wir User als Bugs. Wenn ein Bug auftritt, ist einfach die Problemlösung noch nicht abgeschlossen.
Bei Projekten der Biberei arbeiten wir mit diesem Verständnis. Es geht uns darum, dass unsere digitalen Produkte möglichst schnell einen möglichst hohen Grad der Problemlösung (oder auch Kundennutzen) erreichen. Genau dafür brauchen wir schnelles Feedback. Wir haben also keine Angst vor Fehlern, sondern lernen aus ihnen wie das Problem noch besser gelöst werden kann.
In seinem Buch 15 1/2 Regeln für die Zukunft beschreibt Matthias Horx das Phänomen von Trends und Gegentrends. Er benutzt das Bild eines Pendels, dass stark in eine Richtung ausschlägt und danach etwas weniger stark eine Gegenbewegung vollzieht. Dieses Bild ist aus meiner Sicht sehr passend um den Trend zum Do-It-Yourself (DIY) der letzten Jahre zu beschreiben und einzuordnen.
Wie bereits oben beschrieben handelt es sich bei der Softwareentwicklung um eine kreative und schöpferische Tätigkeit. Damit einher geht auch ein gewisses Streben nach Selbstverwirklichung. Dieses Streben lässt uns Softwareentwickler oft dazu tendieren Dinge selbst - und nach unseren Vorlieben - zu entwickeln. Leider verlieren wir dabei zu oft das Problem bzw. den Kundennutzen aus den Augen. Diese Liebe zum DIY haben wir in den letzten Jahren vermehrt in Softwareprojekten gesehen, bei denen selbst (als Unternehmen oder auch als Dienstleister) Komponenten entwickelt werden. Verstärkt wird dieses Vorgehen noch durch die Abrechnungsmodelle vieler Software-Dienstleister. Sie verkaufen Stunden eines Entwickler - es ist klar, dass hier der Anreiz zum viel länger währenden DIY besteht. Diese Entwicklung betrachte ich als einen Ausschlag des Pendels.
Bei der Biberei setzten wir uns dafür ein, dass das Pendel wieder in die andere Richtung bewegt wird. Wir setzen in jedem Projekt auf die Verwendung von Standardkomponenten, Frameworks und passenden Technologien. Das heißt auch, dass wir einen Teil der Komponenten individuell entwickeln und einen anderen Teil hinzukaufen. Wir entwickeln also nur dort selbst, wo echter Kundennutzen geschaffen wird und es keine passende Lösung am Markt gibt. Das machen wir aus zwei guten Gründen:
In vielen Unternehmen und Projekten werden Investitionsentscheidungen über Softwareprojekte anhand von Business Cases getroffen. Oft wird dabei eine schnelle und teure (z.B. ein bezahlter Service für einen e-Commerce Warenkorb wie commercetools) Lösung gegen eine etwas langsamere, aber günstigere Lösung (z.B. die Eigenentwicklung eines warenkorbs) abgewogen. Unter finanziellen Aspekte betrachtet, wird die Entscheidung meist im Sinne der Eigenentwicklung getroffen.
Aber Achtung: hier verstecken sich gleich mehrere fehleranfällige Denkmuster:
Wir können also durch die Entwicklung unter Einbezug von Angeboten am Markt nicht nur schneller sein, sondern auch noch den besseren Business Case umsetzen. Die Grafik verdeutlicht meine Argumente.
Wir sehen hier einen Business Case mit vier Perioden. Die Summe der Kosten für den bezahlten Service übersteigt die Summe der Kosten für die Eigenentwicklung. Was allerdings allzu gern außer Acht gelassen wird sind unbeachtete Kosten. Das umfasst zum Beispiel den Betrieb, die Wartung, Bugfixes und den Support der Eigenentwicklung. Diese Kosten setzen sich über die betrachteten Perioden des Business Cases hinaus fort. Das ist ebenso der Fall für die kontinuierlichen Kosten eines bezahlten Services. Was jedoch noch verschärfend hinzukommt ist, dass die Lücke zwischen dem Nutzen des Services und der Eigenentwicklung stetig größer wird.
Unsere bisherige Projekterfahrung hat uns gelehrt die unbeachteten Kosten ebenso wie den Unterschied im Nutzen in unser Denkmodell eines Softwareprojekt miteinfließen zu lassen. Bei der Biberei wägen wir also stets ab, ob es wirklich von Vorteil ist einzelne Komponenten oder eine ganze Lösung selbst zu entwickeln.
Damit ein Softwareprojekt als nachhaltig und sinnvoll erachtet werden kann, muss es ein echtes Problem lösen und damit einen Kundennutzen stiften. Daher fragen wir uns stets, welche Komponenten eines digitalen Produktes echten Kundennutzen stiften.
Ein sehr nützliches Modell liefert uns hier Simon Wardley mit der Wardley Map. In der Wardley Map werden Software-Komponenten entsprechend ihres Kundennutzen (value) und ihres Reifegrades (commodity) eingeordnet. Die x-Achse beschreibt den Reifegrad und reicht von commodity (rechts) zu custom-made (links). Die einzelnen Komponenten bilden dabei einen ungerichteten Graphen.
Im Prozess, in dem wir Software(-architektur) entwerfen, halten wir uns dieses Modell vor Augen. Das Ziel dabei ist es nur Komponenten individuell zu entwickeln, die neuartig (weit links) sind und einen hohen Kundennutzen (weit oben) haben. Das anlegen einer solchen Map hilft dabei zu erkennen, worauf wir uns bei der Softwareentwicklung fokussieren sollten und damit das bereits oben erläuterte Phänomen des DIY zu vermeiden. Wir sehen hier eine Wardley Map für verschiedene Software-Komponenten, die eine Wartungsvorhersage für das private KFZ ermöglichen.
Unser Ziel als Biberei ist es dabei stets die angedeute Fokussierung (gestrichelte Linie) in Richtung der neuartigen Komponenten mit hohen Kundennutzen zu verschieben. Die Komponenten unterhalb und rechts der Linie sollten nicht individuell entwickelt werden.
Die Qualität eines digitalen Produkts lässt sich in vielerlei Metriken messen, die der Praxis Softwareentwicklung entspringen. Hier spielen für mich vor allem die Testbarkeit, die Wartbarkeit, die Ausfallsicherheit, die Verständlichkeit (für Softwareentwickler und User) und auch die Modularisierung (Entzerrbarkeit der Software in einzelne Komponenten) eine große Rolle. Um diese Kriterien möglichst gut zu erfüllen, gibt es ganze Bücher mit vielen sinnvollen Ratschlägen und Methoden (Test-Driven-Development, Softwarearchitektur, Softwaredesign-Prinzipien, etc.).
Was jedoch oft mit einem mangelnden Verständnis begleitet ist, ist die Frage wann man besonders an der Qualität arbeiten sollte. Dazu lohnt es sich den Lebenszyklus eines digitalen Produktes zu betrachten. In seinem Buch The Lean Startup beschreibt Eric Ries, dass ein Produkt möglichst schnell auf dem Markt gebracht werden sollte, um so wertvolles Feedback zu sammeln und so wichtige Hypothesen bezüglich des Produktes zu validieren. Dieses Vorgehen beschreibt aus meiner Sicht die erste Phase des Lebenszyklus'.
Wenn nach einer längeren Phase der Hypothesenvalidierung wichtige Erkenntnisse in das digitale Produkt eingeflossen sind, kann ein Unternehmen beginnen es zu skalieren. Das heißt, dass jetzt mehr und mehr User einen Nutzen erkennen und das Produkt annehmen. Hier beginnt sich die Entwicklung für das Unternehmen auszuzahlen und es muss eventuell auftretende Probleme der Software behoben werden. Später geht der Lebenszyklus über in eine Phase in der das Produkt nur noch wenig neuen Nutzen generiert. Der schwierigste Teil hier ist für Unternehmen zu erkennen wie neuer Nutzen hinzugefügt oder wann das Produkt eingestellt werden sollte.
Wir sehen die drei Phasen in der Darstellung. Explore als erste, lange Phase mit Payoff. Die zweite, kurze Phase mit einem steigenden Payoff (Expand) und letztliche die dritte Phase Extract, in der nur wenig neuer Nutzen geschaffen wird. Dieses Modell geht zurück auf Kent Becks Artikel The Product Development Triathlon.
Dieses Modell ist sehr simpel aber ebenso aussagekräftig. Es hilft uns dabei zu verstehen, wann wir in Qualität (im Sinne der oben genannten Kriterien) investieren sollten. In der Explore-Phase ist es unser Ziel möglichst schnell Hypothesen zu validieren. Stellen sich diese als falsch heraus, kann es sogar sein das große Teile der Software verworfen werden können. Es macht also gar keinen Sinn in besonderem Maße in Qualität zu investieren. Ganz anders sieht es in der Expand-Phase aus. Hier haben wir bereits gezeigt, dass unser digitales Produkt Nutzen stiftet. Also ist es jetzt angebracht dafür zu sorgen, dass es auch zuverlässig ist. Das heißt natürlich nicht, dass wir nur in der Expand-Phase auf Qualität achten sollten. Vielmehr müssen wir besser verstehen wann wir uns besonders (nicht ausschließlich) auf welche Aspekte des Produktes fokussieren sollten.
Das letzte wichtige Denkmodell bezieht sich auf die Arten von Arbeit, mit denen wir es in der Softwareentwicklung zu tun haben. Diese grobe Abstraktion der verschiedenen Tätigkeit beruht auf der Mik Kerstens Analyse vieler Unternehmen und derer Wertströme in der Softwareentwicklung. Das Kondensat dieser Analyse sind die folgenden vier Kategorien von Arbeit:
Es gibt hier zwei wichtige Aspekte, die zum Verständnis von Softwareentwicklung beitragen. Der erste Aspekt ist, dass es mehr Arbeit gibt als die von außen wahrnehmbaren Feature. Jede der vier Arten von Arbeit ist wichtig. Eine gute und ökonomisch sinnvolle Software kann nur unter Beachtung all dieser Kategorien von Arbeit entstehen.
Der zweite wichtige Aspekt bezieht sich auf die Kapazität, die ein Softwareenwicklungsteam hat. Es müssen alle vier Arten von Arbeit getan werden. Die Anzahl der Aufgaben die bearbeitet werden können entspricht der Kapazität des Teams. Innerhalb der Kapazität können diese verschiedenen Aufgaben verteilt werden. Dabei ist es so, dass eine Übergewicht in einer Kategorie zu einem Mangel in einem anderen Bereich führt. Entwickelt ein Team beispielsweise über lange Zeit nur Features, wird es später viel Kapazität in Debt, Risk und Defects stecken müssen - das ist ein Nullsummenspiel. Wir können nicht über lange Zeit eine einseitige Verteilung aufrecht erhalten.
Das Schaubild zeigt eine exemplarische Verteilung, die sich auch gut auf die drei Phasen des 3X-Modells beziehen lässt. In der Explore-Phase ist es durchaus sinnvoll viel Kapazität in Features zu investieren. Wir müssen aber dafür in der Expand- und Extract-Phase Debt abbauen und eventuell Risiken mitigieren. Ein weiterer Aspekt, der oft unterschätzt wird ist, dass viele Defects erst aufgedeckt werden, sobald man in die Expand-Phase übergeht. Die Begründung haben wir bereits in dem Abschnitt zum komplexen Problem gesehen. Man muss also damit rechnen, dass nach einem Release, die Anzahl der umgesetzten Features zu Gunsten von Defects sinkt.
Bei der täglichen Arbeit helfen uns diese Kategorien und deren Verteilung dabei Verständnis zu schaffen, Erwartungshaltungen zu managen und auf Unsicherheiten vorbereitet zu sein. Daher ist dies eines der wertvollsten Denkmodelle.
Wir haben gesehen, dass Softwareentwicklung ein kreativer Prozess ist, der probiert komplexe Probleme zu lösen. Daraus können wir ableiten, dass Software (fast) nie fertig ist und schnelles Feedback eines der wichtigsten Mittel ist, um sich im Bereich der komplexen Probleme behaupten zu können. Aus der Kreativität, die wir für die Softwareentwicklung brauchen leitet sich ein Selbstanspruch ab. Dieser Anspruch lässt uns oft Software selbst entwickeln - die Entwicklung wird dabei zum Selbstzweck.
Dieser Trend sorgt allerdings dafür, dass viele Projekte unnötig teuer sind und zu viel Zeit in Anspruch nehmen. Hier hilft es auf Wardley Maps zurückzugreifen, um sich vor Augen zu führen welche Komponenten individuell entwickelt werden und welche wiederum vom Markt bezogen werden können. Letztlich haben wir einen Blick darauf geworfen, wie man mit Qualität im Kontext des Produktlebenszyklus umgehen sollte. Hierbei kann man in der Phase der Hypothesenvalidierung durchaus auf einen hohen Qualitätsanspruch verzichten, um dafür an Geschwindigkeit zu gewinnen. Bei dieser Entscheidung hilft das Verständnis über die Arten von Arbeit in der Softwareentwicklung. Die Konzentration auf Features und Hypothesenvalidierung am Beginn des Lebenszyklus kann mit verstärkter Fokussierung auf technische Schulden und Defects in späteren Phasen ausgeglichen werden. Der Vorteil dabei ist, dass man nur in Software investiert, die ihren Nutzen schon am Markt bewiesen hat.
Erzähle uns in einem kostenlosen Erstgespräch mehr über dein individuelles Projekt. Wir helfen dir bei den nächsten Schritten und teilen unser Wissen.
Nachricht schreiben