Codequalität: Hört auf an der falschen Stelle zu sparen

An der Codequalität sparen bedeute langfristig mehr Kosten.

Zeit ist Geld. Codequalität kostet Zeit und ist damit eine Mehrinvestition, die von den Projektleitern/Product Ownern häufig stiefmütterlich behandelt wird. Insbesondere beim Übergang vom Prototypen zur finalen Applikation wird der Rotstift angesetzt. Doch dieses Vorgehen kann auf langfristige Sicht mehr Geld kosten, als es kurzfristig gespart hat. Wir zeigen heute die Gründe dafür und wie Codequalität der Entwicklung zum Erfolg verhelfen kann.

Was will Codequalität/Clean Code?

Unter dem Label Codequalität oder dem von Robert C. Martin geprägten Begriff des Clean Codes ist eine Sammlung von Vorgehensempfehlungen für die Entwicklung von Software zu verstehen, welche auf verständlichen Code abzielen. Die genauen Vorstellungen unterscheiden sich dabei genauso, wie die an die eigene Realität angepasste Umsetzung.
Im Netz gibt es einige empfehlenswerte Artikel und Diskussionen, die sich mit dem Thema auseinandersetzen. Dabei gibt es umfangreiche Auslegungen, wie bei den Clean Code Developers, welche sogar das Tragen von farbigen Armbändern als Repräsentation für die erreichten Grade vorschlagen. Bei secu-ring erfreuen sich die Bücher von Robert C. Martin großer Beliebtheit, geben sie doch eine Vielzahl an Empfehlungen zu Themen wie Codeformatierung oder Refactoring. Allen Empfehlungen gemeinsam ist die Behauptung, dass Code häufiger gelesen als geschrieben wird. Besonders die Einarbeitung in komplexe Parts braucht somit viel Zeit.

Hier beginnt unser Ansatz, dass Codequalität zwar initial mehr Zeit und Budget benötigt, sich dies aber schnell rentieren kann: Üblicherweise ist Software auf eine langfristige Nutzungsdauer angelegt, um die Entwicklungskosten zu amortisieren und für den Product Owner Gewinn einzufahren. Innerhalb der Laufzeit benötigt die Anwendung Wartung, um beispielsweise browserbasierte Anpassungen durchzuführen. Mit Weiterentwicklungen kann dagegen auf neue Bedürfnisse der Anwender oder geänderte Anforderungen reagiert werden. Diese Möglichkeiten sollten schon in der grundlegenden Entwicklung mit eingeplant werden, sonst kann das Produkt schon bei Release von der Realität überholt worden sein. Die Konsequenz wäre die Abschreibung des gesamten Budgets als Fehlinvestition.

Nachhaltige Entwicklung bringt klaren Langzeitnutzen

Vor dem eigentlichen Produkt wird oft ein Prototyp entwickelt, welcher die grundsätzliche Umsetzbarkeit der Idee demonstrieren soll. Wenn alle Stakeholder zufrieden mit dem Ergebnis sind, muss es in eine produktive Version überführt werden.

Eine sinnvolle Vorgehensweise wäre, bei der Entwicklung des eigentlichen Produktes von vorn anzufangen und dort auf die Qualität der Quellcodebasis zu achten. Bei begrenztem Budget ist gesunder Pragmatismus gefragt: Muss sich das Produkt schnell am Markt monetarisieren, empfiehlt sich der Einsatz des Prototyps als klar deklarierte Early-Access-Version. Sie ermöglicht einen schnellen Marktstart und das Sammeln und die Analyse von wertvollem Feedback. Das eigentliche Produkt sollte derweil gleichzeitig als MVP entwickelt und später ausgebaut werden.

Mit der Wartung oder Erweiterung rentiert sich eine solide Codequalität für die Product Owner wie auch für die Entwickler. Das Produkt kann auch von neuen und externen Entwicklern leicht verstanden werden. So hält sich die Einarbeitungszeit in Grenzen und Verbesserungen können schneller eingepflegt werden. Die Product Owner, das Produkt wie auch die Entwickler bleiben flexibel.
Diese Flexibilität erfordert anfangs mehr Budget. Features die erst nach dem ersten Release hinzugefügt werden, sind immer teurer. Da über die Laufzeit sowieso Wartung und Erweiterung anstehen, hilft eine gute Codequalität deren Kosten wenigstens zu senken.

Wer billig entwickelt, entwickelt zweimal.

Unter der Prämisse “Zeit ist Geld” wird das finale Produkt häufig auf Basis der Demonstratoren weiterentwickelt und veröffentlicht. Doch Prototypen wurden selten mit hoher Codequalität entwickelt. Im QTK-Dreickeck liegt der Fokus auf Zeit (und Kosten) und nicht auf Qualität. Für eine Demonstration ist dieser Umstand okay.
Was passiert, wenn mit dieser schlechten Basis weitergearbeitet wird? Für die Einarbeitung in und die Korrektur von schlechtem Code wird enorm viel Zeit benötigt. Damit steigt der Aufwand für Wartung und Weiterentwicklung überproportional an. Das Ergebnis ist dennoch nicht zufriedenstellend oder weist gravierende Mängel, z.B. bei der Sicherheit, auf. Die Einsparungseffekte der ursprünglichen Entscheidung sind damit schnell aufgebraucht und kehren sich ins Gegenteil um.
Ähnlich verhält es sich bei Konsumgütern: Ein Produkt mit dem Fokus auf Kosteneinsparung ist selten wartungsfreundlich oder auf eine lange Nutzungsdauer ausgelegt. Notwendige Reparaturen sind meist nicht mehr möglich oder übersteigen den Neuwert. Eine Neuinvestition wird so unausweichlich. Doch Software kann schlecht per Expressversand nachbestellt werden.

Die Vorteile einer Neuentwicklung mit Fokus auf eine gute Codequalität liegen auf der Hand: Der Product Owner bekommt eine gut funktionierende Applikation, welche sich während der Laufzeit leicht warten lässt. Er erhält die Flexibilität, das Produkt auf neue Anforderungen hin anzupassen und so den Mehrwert zu steigern. Dabei ist er nicht auf den ursprünglichen Entwickler angewiesen. Er kann auch das eigene Softwareteam erweitern und externe Dienstleister hinzuziehen. Mit diesem modularen Ansatz lassen sich auch unnötige Parts schneller wieder entfernen oder gegen bessere Lösungen austauschen ohne eine komplette Neuentwicklung starten zu müssen. Die Mehrinvestition zum Start der Entwicklung rentiert sich damit schnell während der Nutzungsdauer, denn auch hier gilt: Zeit ist Geld.

Der zweite Teil dieses Artikels erklärt, wie ein Entwicklerteam Clean Code bzw. Codequalität umsetzen kann und daraus den maximalen Nutzen erzielen kann.

 

Coverbild: Basierend auf Urheber: inueng / 123RF Lizenzfreie Bilder

2 responses on “Codequalität: Hört auf an der falschen Stelle zu sparen

  1. Andreas Bungert

    Aus meiner Zeit als Vorstand eines Softwareunternehmens weiß ich aus eigener Erfahrung, dass sich die Performanz von Softwareentwicklern ohne weiteres in einer Größenordnung des Faktors 10 unterscheiden kann. In kaum einem anderen Berufsbild sind solche Leistungsunterscheide möglich. Kein guter Maurer schafft es, das 10-fach eines langsamen Kollegen zu leisten.

    Das übliche Projekt-Sourcing belohnt diese Leistungsträger jedoch nicht. Besonders Konzerne aber auch kleine Internet-Startups wollen nur „mit Bananen bezahlen“. Dass sie dafür nur“Affen“ bekommen, darf nicht wundern. Controller und Einkäufer halten sich für toll, da sie die „Stückkosten“ gedrückt haben. Dass sie sich dafür aber gering qualifizierte oder wenig qualitätsbewusste Leute einkaufen und damit die Gesamtkosten in die Höhe treiben, ist das Problem des Projektleiters.

    Vielleicht spielt hier falsch verstandene Agilität auch eine Rolle. Wenn ich immer schnell, schnell alles fertig haben will und nur von einem Sprint bis zum nächsten denke, also rein auf Sicht fahre, dann werde ich mir zwangsläufig für die Zukunft jegliche Agilität zu verbauen. Code-Qualität ist kein Luxus, es ist eine Investitionssicherung. Deshalb sind diese Aufgaben in den agilen Methoden auch berücksichtigt. Was leider zu oft Theorie bleibt.

    Einen erfolgsentscheidenden Punkt dürfen die Software-Entwickler aber nicht außen vor lassen, auch wenn er nicht in ihrem Verantwortungsbereich liegt: die Anforderungen. Meist ist deren Qualität schon schlecht. Sie sind widersprüchlich, wichtige Dinge werden vergessen, bis hin zu ganzen Prozessen und Szenarien, die komplett übersehen werden. Die Folge: man muss eh öfter alles wieder umbauen. Also wozu in Codequalität investieren? Wenn ich meinen Bedarf nicht geklärt habe, wird das was gebaut wird, auch nicht das leisten, was gebraucht und erwartet wird. Ob mit guter Codequalität oder ohne. Die Codequalität wird jedoch enorm wichtig, sobald sich der Bedarf ändert und es ans Umbauen oder Erweitern der Software geht. Dann zeigt sich, wie agil man wirklich ist.

    Meine Oma sagte schon: „Wer sparen will, kauft nix billiges. Denn dann kauft er zweimal.“ Ein Mindestmaß an Qualitätsbewusstsein, sowohl bei den Leistungen der Software-Entwickler, aber auch bei den Leistungen der Fachseite, würde vielen Projektbudgets gut tun.

  2. Olaf Stichtenoth

    Bei aller Qualität sollte man zusätzlich auf die Schlankheit (lean) des Gesamtsystems geachtet werden. Viele Features und Regeln erhöhen zwangsläufig die Komplexität und was nicht im System ist, muss auch nicht gewartet werden.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.