Die New Economy der frühen 2000er kündigte sich noch mit einem Donnerschlag an – man denke nur an die Fintechs, die mit ihrer technologiege-triebenen Entwicklung angetreten sind, den Finanzsektor auf den Kopf zustellen. Weitgehend unbemerkt erreicht diese Revolution mittlerweile auch die traditionellen Branchen. So hat selbst Volkswagen angekündigt, seine Marke in Zukunft über die Software zu definieren, und bündelt dazu in der neuen Einheit »Car.Software« die Kompe-tenz von mehr als 5.000 Digitalexperten. Doch ganz gleich, wo man hinschaut: Von den hoch optimierten Produktionsprozessen der Industrie ist die Softwareentwicklung noch weit entfernt – und das, obwohl die größten Kostenfallen längst bekannt sind.
Als Idealfall will der interne oder externe Auftraggeber einer Entwicklung jeden Euro des investierten Budgets in volle 100 Cent Softwareinnovation umgesetzt sehen«, sagt Marc Hildebrandt, CEO und Gründer des Technologie-Inkubators German Deep Tech, der akademische Exzellenz in industriell nutzbare Softwarelösungen transformiert. »Wenn die Teams jedoch größer und die Projekte komplexer werden, entfernt man sich von diesem Ziel zwangsläufig immer weiter, weil mehr Budget auf Nebenschauplätzen auf der Strecke bleibt.«
Kostenfalle:
Fehlerbehebung verschleppen.
Auch wenn es trivial klingt: Die Fehlerbehebung macht den größten unproduktiven – und obendrein unvorhersehbaren – Anteil an der Arbeitszeit von Entwicklern aus. Damit ist nicht nur das routinemäßige Testen der Software als Teil des Release-Zyklus gemeint. Richtig problematisch sind die Fehler, die es bis zu den Endanwendern geschafft haben. Das Managementsystem zur Prozessverbesserung Six Sigma kennt dafür die Zehnerregel: Die Kosten für einen nicht entdeckten Bug erhöhen sich von Stufe zu Stufe der Wertschöp-fung um den Faktor 10. Je früher ein Fehler entdeckt und beseitigt wird, desto kostengünstiger ist dies also für die Or-ganisation.
Vor allem sind spät gefundene »Defects« im ausgelie-ferten Code für die Entwickler frustrierend, weil sie häufig mit viel Aufwand und unter Zeitdruck behoben werden müssen, während die eigentlichen Aufgaben hintangestellt werden. Erfolg und Motivation im Team langfristig aufrecht-zuerhalten und zugleich die Fehlerbehebung zu optimieren kann eine große Herausforderung an die Arbeitsorganisation bedeuten – ob nun einzelne Entwickler dafür verantwortlich zeichnen oder die Last gleichmäßig verteilt wird. »Letzten Endes muss sich das Team nun entscheiden, was sich besser anfühlt: Abwechselnd Freiwillige, die intensiv Bugfixing betreiben und für Anfragen zur Verfügung stehen, oder paral leles Arbeiten, das auf jeden Fall ablenkt und den Fokus verlieren lässt«, fasst Dr. Markus Friedrich, Spez. Entwick-lung – Architektur Fahrzeugvernetzung bei der BMW Group im XING-Forum »SCRUM« zusammen.
Kostenfalle:
Technische Schulden aufnehmen.
Wenn Software entwickler unter Zeitdruck arbeiten müssen, neigen sie dazu, von den eigentlich getroffenen Vereinba-rungen abzuweichen und unsauber zu programmieren. Das kann im Einzelfall sinnvoll sein, um Release-Termine einzuhalten oder eine schnelle Fehlerbehebung vorzunehmen. Derartige Stellen im Quellcode werden auch als technische Schulden bezeichnet. Die Zinsen dafür zahlen diejenigen Entwickler, die später mit dem Code weiterarbeiten müssen, etwa um ihn zu erweitern. Sie benötigen mehr Zeit, sich ein-zuarbeiten, kommen langsamer voran und machen dabei mit größerer Wahrscheinlichkeit Fehler.
So sinnvoll die Aufnahme technischer Schulden in begründeten Einzelfällen auch sein mag – die Entscheidung gegen eine saubere Lösung fällt von Mal zu Mal leichter. Aus der Sozialpsychologie ist dieser Effekt als Broken-Windows-Theorie bekannt: An einem Gebäude mit zahlreichen bereits zerstörten Fenstern wird leichter ein weiteres Fenster einge-schlagen als an einem intakten Haus. Wird das Auslassen oder Verkürzen von Prozessschritten zum Normalfall im Entwicklungsteam, entsteht im Lauf der Zeit ein Flickenteppich an nicht-konformem Code, der kaum noch zu pflegen ist.
Abbildung 1: Visualisierung eines komplexen Code-Systems mit Software Analytics.
Kostenfalle:
Altlasten anhäufen.
Technische Schulden sind Altlasten, die den Entwicklungs-prozess so sehr behindern können, dass er nahezu zum Erliegen kommt. Spätestens wenn beim Auftraggeber der Eindruck entsteht, das Team sei nur noch mit sich selbst beschäftigt, führt kein Weg mehr an einem operativen Eingriff in den Code vorbei. Dieser kann minimalinvasiv als Refactoring erfolgen – immer, wenn betroffener Code ange-fasst werden muss, wird an dieser Stelle die Altlast gleich mit beseitigt – oder gemeinsam im Team als groß angelegtes Redesign des Codes auf einen Schlag erledigt werden.
»Ob im eigenen Haus oder extern, ob von Hand oder mit Werkzeugunterstützung – die Beseitigung von Altlasten lässt sich optimieren, aber immer müssen Zeit und Geld investiert werden, die dann nicht mehr für die eigentliche Entwicklungsaufgaben zur Verfügung stehen«, sagt Günter Hofmann, Geschäftsführer des Anwendungsmodernisierungs-Dienstleisters fecher. Trotzdem lohnt es sich aus seiner Sicht, diesen Aufwand eher früher als später zu betreiben: »Die größte Überraschung für die Entwicklungsteams ist es immer, nach Abschluss eines Modernisierungsprojekts zu sehen, wie viel leichter die Weiterentwicklung nun von der Hand geht.«
Abbildung 2: Die größten Kostenfallen in der Softwareentwicklung.
Kostenfalle:
Wissensmonopole zulassen.
In einem komplexen Softwareprojekt mit Hunderttausenden von Zeilen kann sich nicht jedes Teammitglied auch noch im letzten Winkel der Code-Base auskennen. Gefährlich wird es jedoch immer da, wenn Wissensmonopole entstehen und der Erfolg von einigen wenigen Experten abhängt. Im Risiko-management lassen sich solche Monopole durch den Bus-Faktor beschreiben: Wie viele Personen würden das Projekt ernsthaft in Gefahr bringen, »wenn sie von einem Bus über-fahren werden«. Diese plakative Beschreibung schließt harmlosere Ausfallgründe wie Krankheit oder Verlassen des Unternehmens natürlich mit ein.
»Stellen Sie sich einfach vor, ein Schlüsselmitarbeiter des Projekts fällt überraschend für zwei oder drei Wochen aus«, sagt Dr. Martin Kuhlmann, Senior Solution Architect bei Omada. Wenn dann das ganze Projekt stehen bleibt, andere Entwickler eine lange Einarbeitungszeit benötigen, bis sie einspringen können, und mit dem unbekannten Code nur langsam vorankommen, zeigt sich die ganze Proble-matik. »Die Abhängigkeit von einzelnen Mitgliedern ist immer eine große Gefahr für das Team«, betont Kuhlmann. Gegensteuern lässt sich beispielsweise mit agilen Vorgehensmodellen, die einen regelmäßigen Austausch fördern und die Verantwortlichkeit für den Code auf alle Entwickler verteilen.
Software Analytics zeigt Ansatzpunkte. Einschlägige Schätzungen taxieren die Verluste durch Kostenfallen wie die genannten bereits in mittleren Entwicklungsprojekten auf über 50 Prozent. In großen, komplexen Projekten summieren sie sich leicht zu 80 oder 90 Prozent auf. »Wenn nur 20 Prozent der eingesetzten Produktivmittel den eigentlichen Zweck erfüllen, würde man in der Business-Welt doch schnellstens handeln«, befindet der Deep-Tech-Unternehmer Hildebrandt. »Wie können wir das ausgerechnet in unserer hoch technisierten Softwarewelt akzeptabel finden?«
Tatsächlich wird selbst in Fortune-500-Unternehmen die Entwicklung komplexer Softwaresysteme bislang eher als Kunstform denn als Ingenieurwissenschaft gehandhabt. Der Prozess zerfällt in verschiedene Aufgabenbereiche, in denen jeweils eigene Sprachen und Sichtweisen vorherrschen und isolierte Softwarewerkzeuge zum Einsatz kommen. Agile Methoden können mit ihren Organisationsformen das Silo-problem etwas lindern, ändern aber auch nichts daran, dass der Prozess quer durch die Expertisenfelder verläuft. Somit muss eine ständige Übersetzung zwischen den Artefakten und Sprachwelten stattfinden und die Nachverfolgbarkeit des Prozesses bleibt gerade im Enterprise-Kontext, wenn mehrere Teams zusammen an einem großen System entwickeln, reines Wunschdenken. Wollen sich die Verantwortlichen im Management einen Überblick verschaffen, müssen sie Informationen bei den jeweiligen technischen Experten einholen und sind dabei in Ermangelung einer gemeinsamen Datengrundlage und Sprache mit den technischen Experten schlussendlich auf ihr Bauchgefühl angewiesen.
Ähnlich wie in der Business-Welt Big Data und Business Intelligence (BI) dazu geführt haben, dass das Management jederzeit verlässliche Entscheidungsgrundlagen auf Basis harter Fakten zur Verfügung stehen, will die verhältnismäßig neue Disziplin der »Software Analytics« dies mit dem Prozess der Softwareentwicklung ebenfalls erreichen. »In Reposito-rien und all den anderen Werkzeugen haben wir ausgezeichnete, präzise Daten über alle wesentlichen Aspekte der Softwareentwicklung vorliegen«, erläutert Prof. Jürgen Döllner vom Hasso-Plattner-Institut für Digital Engineering (HPI) in Potsdam. »Bislang fehlte schlicht und ergreifend die Erkenntnis, dass man aus diesen Daten wertvolles Wissen generieren kann.«
Letzten Endes erhält der Auftraggeber mehr Innovation für
sein investiertes Budget
Gezielte Verbesserungen umsetzen. Dieses Wissen entsteht erst, wenn man den komplexen Prozess der Softwareentwicklung vom Anforderungsmanagement über die Codierung und das Testen bis zum Release Management betrachtet. »Nur wer weiß, wo im Gesamtprozess die Verluste entstehen, kann sinnvoll gegensteuern«, erläutert Geschäftsführer Dr. Johannes Bohnet von Seerene. Dazu bietet die HPI-Ausgründung in ihrer Seerene-Analytics-Plattform Business-Dash-boards, auf denen sich die einzelnen KPI-Kennzahlen in Echtzeit verfolgen lassen. Bei Abweichungen vom Soll-Wert können alle Beteiligten, vom Manager bis zu den Experten, dann per Drill-Down zur genauen Ursache vorstoßen.
Verbringt das Team beispielsweise zu viel Zeit mit Fehlerbehebung, lässt sich exakt analysieren, an welchen Stellen in der Code-Base die Probleme entstehen und wo die Entwickler ihre Zeit beim Beheben von Fehlern tatsächlich verbringen. »Diese Art von Wissen ist extrem wertvoll, weil sie Konsequenzen hat: Wie ein Chirurg kann ich nun die Hand-voll Stellen im Code reparieren, um die es wirklich geht«, so Bohnet. Die eingesparte Zeit steht dann zusätzlich für produktive Arbeiten zur Verfügung. »Letzten Endes erhält der Auftraggeber mehr Innovation für sein investiertes Budget«, freut sich der Software-Analytics-Experte. »In nahezu jedem Softwareprojekt lässt sich so ad hoc ein Produktivitätszuwachs von über 30 Prozent erreichen.«
