Technische Schulden und Code Audit – Bauen nachhaltiger Produkte
Technische Schulden sind für die IT-Branche kein unbekannter Begriff und oftmals Teil bei der Entwicklung neuer Produkte. Denn vorherrschender Druck am Markt, wachsender Wettbewerb untereinander und hohe Ansprüche seitens der Kunden erhöhen bei der Entwicklung und Umsetzung eines Produkts die Anfälligkeit für Fehler – und genau diese Fehler nennen sich technische Schulden.
Technische Schulden haben einen durchaus negativen Ruf und sind nicht gerne im Unternehmen gesehen, da sie durchaus auch gravierenden Einfluss auf das Unternehmen haben können. Was viele jedoch nicht wissen: Technische Schulden können für Prozesse im Nachhinein auch sehr hilfreich sein. Doch wie gelingt ein angemessener Umgang mit technischen Schulden? Was für Folgen können sich daraus ergeben? Und inwiefern hängen technische Schulden mit der Entwicklung nachhaltiger digitaler Produkte zusammen?
Die "Debt Metaphor": Was sind überhaupt technische Schulden?
Der Begriff der technischen Schuld – auch Tech Debt oder Code Debt genannt – tauchte erstmals im Jahr 1992 auf. Der US-amerikanische Programmierer und Erfinder von Wiki-Systems, Ward Cunningham, verwendete ihn in Bezug auf die Unternehmens-IT. Bei seiner Arbeit für das Portfoliomanagement-Systems WyCash, befasste er sich mit der Frage des Refactorings, die Restrukturierung einer Software. Es ist einer der letzten Schritte bei der Produktentwicklung und dient dazu, den Code und dessen Struktur aufzuräumen und zu perfektionieren. Wenn ohne die Berücksichtigung der Skalierbarkeit gearbeitet wird, entstehen technische Schulden. Sie werden nicht immer absichtlich erzeugt, sondern entstehen ganz natürlich aus dem Prozess heraus. Sobald das Team diese bemerkt, soll der Code durch die Restrukturierung der Software verbessert und das Problem gelöst werden.
Noch heute erinnert sich Cunningham gerne an die Entstehung des Konzepts zurück: "Sich Geld zu leihen, verleiht einem die nötige Flexibilität. Denn es befähigt uns dazu, bestimmte Dinge schneller oder früher umsetzen, auf die wir sonst aufgrund mangelnder finanzieller Mittel warten müssten. Ich hielt es für eine gute Idee, sich Geld zu leihen. Genauso dachte ich, es sei eine gute Idee, eine Software möglichst schnell auf den Markt zu bringen, um damit Erfahrungen zu sammeln. Sobald man etwas über die Software gelernt hat, würde man das Darlehen anschließend sofort zurückzahlen, indem man das Programm mit den gesammelten Erfahrungen überarbeitet."
Technische Schulden sind also nicht immer schlecht, denn neu gesammelte Erfahrungen können dabei helfen, den Prozess zu verbessern und die gesetzten Ziele zu erreichen. Refactoring ist für die Weiterentwicklung einer Software unabdingbar, denn nur so kann sich eine Software verbessern. Ein Unternehmen sollte deshalb die Balance zwischen den Vorteilen und den technischen Schulden finden, um diese schlussendlich effektiv nutzen zu können.
Technische Schulden bei digitalen Produkten - die Ursachen
Um technischen Schulden rechtzeitig entgegenzuwirken bzw. sich von ihnen nicht verunsichern zu lassen, ist es wichtig, dass das Entwicklerteam und die dazugehörigen Teamleiter wissen, wie und wodurch technische Schulden überhaupt entstehen können. Die Ursachen können z. B. folgende sein:
- Unrealistische Zeitvorgaben, die von Teamleitern oder Stakeholdern gegeben werden. Teams geraten dabei noch viel eher unter Stress und bekommen oft Zeitvorgaben von Stakeholdern, die sie nicht einhalten können, da Dritte diesen Aufwand meist gar nicht genau einschätzen können.
- Dies geht Hand in Hand mit einem zu hohen Druck, dem manche Teams ausgesetzt sind. Dadurch arbeiten sie eher unachtsam und Fehler können sich einschleichen.
- Eine zu geringe Qualität des Codes ist häufig ein Grund dafür, dass technische Schulden entstehen können. Umso geringer die Qualität desto mehr Aufwand, diesen zu optimieren.
- Die Entwicklungsfähigkeiten im Team oder der gesamten Abteilung spielen mit die wichtigste Rolle. Sind die Fähigkeiten nämlich unzureichend, können bereits am Anfang eines Projektes Probleme entstehen, die nur schwer behoben werden können.
- Overengineering und übermäßig komplexe Implementierungen können schädlich sein.
- Auch ineffektive Methoden oder Rahmenbedingungen, in denen sich die Mitarbeiter:innen bewegen, können negative Auswirkungen haben. Unter schlechtem Management und einer unflexiblen Herangehensweise kann das Team stark leiden und die Motivation und der richtige Antrieb bleiben auf der Strecke.
- Die Verwendung einer temporären Lösung als Endprodukt, wenn also ein MVP (Minimum Viable Product) für einen längeren Zeitraum genutzt wird.
Das Gute an technischen Schulden
MVPs sind Hilfsmittel zur Risikominimierung, womit Entwicklerteams maximales Wissen mit geringem Aufwand zu Kunden sammeln können. Sie werden in gewissen Situationen absichtlich erstellt, um mögliche Störfaktoren ermitteln zu können. Im Mittelpunkt stehen dabei die geschäftlichen Anforderungen, die Qualität, die Funktionalität und die Geschwindigkeit, die eine Software aufweist. Es wird in einer bestimmten Phase des Prozesses also absichtlich eine noch nicht voll funktionierende App entwickelt, die dadurch aber so schnell wie möglich auf dem Markt platziert werden kann. Das verschafft dem Unternehmen den Vorteil, frühzeitig Feedback für das Produkt zu bekommen und sich anhand dessen zu verbessern. Unternehmen gehen also bewusst dieses Risiko ein und nehmen technische Schulden in Kauf. Das Entwicklerteam ist sich über die Unvollkommenheit der App natürlich bewusst und nicht davor geschützt, weitere Funktionen während des schnellen Entwickelns übersehen zu haben. Der Lerneffekt dieser Herangehensweise ist am Ende ausschlaggebend, sodass sich dabei sogenannte positive technische Schulden bilden können.
Sobald ein Produkt verbreitet wird, sollten technische Schulden definitiv vermieden werden.
Schlussendlich wird damit die Geschäftshypothese getestet, es folgt eine Validierung aller bisheriger Annahmen und der Verlauf wird als positiv oder negativ bewertet. Sobald das geschehen ist, wird entschieden, ob die App komplett verworfen wird oder ob sich der weitere Aufwand lohnt, das MVP zu verbessern und weiterzuentwickeln. Sobald ein Produkt allerdings verbreitet wird und die Erschließung eines neuen Marktes stattfindet, sollten technische Schulden definitiv vermieden werden. Wenn technische Schulden nun entstanden sind, ist es für die Teams ein klares Zeichen dafür, dass im Laufe des Prozesses Fehler aufgetaucht sind und Entscheidungen getroffen werden mussten, die das einst geplante Endprodukt geändert haben. Es wurden Lösungen entwickelt, die letzten Endes einen Einfluss auf das Produkt haben. Wichtig ist: Sollten technische Schulden entstehen und diese auch rechtzeitig entdeckt werden, sollte das Team und das Unternehmen darauf reagieren und sofort handeln. Denn sonst können die technischen Schulden irreparabel werden und im Nachhinein mehr Zeit für die Aufbereitung in Anspruch nehmen.
Die Folgen der technischen Schulden
Technische Schulden sind meist negativ behaftet, können aber auch einen positiven Einfluss haben – und Entwickler haben nicht immer eine Wahl, ob und wann diese entstehen. Im Umgang mit technischen Schulden gibt es mehr als eine Methode, eine davon ist die Test-Driven-Development-Methode (TDD). Das Hauptziel dieser Methode ist die Skalierung und nicht die Validierung, das bedeutet, dass die technischen Schulden nicht komplett aufgehalten werden können, sondern dass der Code lediglich in einen gesunden Zustand gebracht wird. Ganz typische Probleme, die auftauchen, können beispielsweise Bugs, Datenlecks, schlechte Leistung oder Fehlfunktionen sein. Wenn sich das Entwicklerteam diesen Fehlern widmet und anfängt, sie zu bearbeiten, dauert der Bearbeitungsprozess nicht nur länger, sondern kann zudem sehr strapazierend sein. Das Team muss sich ständig über den Status des Produkts bewusst sein und die Umstände genau einschätzen können. Das ist wichtig, da es bei der Entstehung von technischen Schulden um Schnelligkeit geht, um den Schaden zu minimieren.
Der Umgang mit technischen Schulden
Nun ist das Unternehmen an einem Punkt, an dem es merkt, dass technische Schulden entstanden sind, eine App soll erneuert werden oder neue Funktionen für Nutzer:innen sollen eingerichtet werden. Für genau diese Situationen gibt es ein paar Tipps und Tricks, die dabei helfen können, die aktuelle Situation zu verbessern und dafür zu sorgen, dass solche Probleme in Zukunft nicht mehr auftreten werden.
Mithilfe des sogenannten Code-Audits können frühzeitig Fehlfunktionen erkannt werden. Es ist ein Programm, das eine umfassende Analyse durchführt, um fehlerhafte Codes aufzudecken. Das Programm achtet während des Durchlaufs auf die Codequalität, die Softwarearchitektur, Sicherheitsmaßnahmen und die Zuverlässigkeit sowie die Leistung des Produkts.
Durch die Hilfe des Code-Audits kann die Lebensdauer eines digitalen Produkts verlängert werden. Die Empfehlungen, die ein Code-Audit geben kann, können sogar dazu führen, den Marktanteil des Unternehmens zu vergrößern und/oder dass das Unternehmen vor weiteren Misserfolgen geschützt wird. Handelt es sich um ein besonders gutes Audit, so werden nicht nur die technischen Aspekte eines Codes analysiert, sondern auch die Designelemente, die das Nutzererlebnis abrunden, einschließlich dem UX/UI-Designs. Wenn das Audit abgeschlossen worden ist, sollten für die folgenden Punkte Ergebnisse und Empfehlungen abgeleitet werden:
- Code-, Architektur- und Speicherverbesserungen,
- Bugs, die behoben werden müssen,
- Sicherheit und Wartung,
- Benutzerführung,
- Gestaltung der Benutzeroberfläche,
- Behebung technischer Schulden und
- Bereitschaft für die nächste Phase der Produktentwicklung oder Geschäftsstrategie (z. B. Skalierung).
Am Ende erhält das Team zu jeder einzelnen Aufzählung eine Handlungsempfehlung mit einer zusätzlichen erforderlichen Kosten-Nutzen-Analyse. Die Probleme sollten auf der Grundlage der Auswirkungen des Produktes, deren Benutzern und Geschäftszielen priorisiert werden. Der künftige Erfolg des Produktes hängt davon ab, wie Probleme angegangen werden. Drei Faktoren sind dafür besonders wichtig: die Nachhaltigkeit des Produkts, das Risikomanagement und der Umgang mit den obengenannten technischen Schulden.
Die Nachhaltigkeit
Sich auf die Nachhaltigkeit eines Produktes zu konzentrieren macht genau dann Sinn, wenn das digitale Produkt eine verlängerte Lebensdauer bekommen soll oder zum Leben erweckt werden soll. Die Nachhaltigkeit bezieht sich dabei auf die folgenden Bereiche: Sicherheit, Skalierbarkeit, Benutzerfreundlichkeit und Wartbarkeit.
Das Risikomanagement
Jedes Projekt ist mit möglichen Risiken verbunden. Das Risikomanagement ist deshalb etwas, das nicht unterschätzt werden sollte. Ein umfassender Rückstand an Aufgaben und Maßnahmen sind der Schlüssel zum Risikomanagement in der Entwicklung. Solch ein Backlog hilft dem Team, den Überblick über bisherige Aufgaben und Schwachstellen zu behalten, um weitere Risiken zu mindern. Das Backlog sollte dabei stets auf die Geschäftsziele ausgerichtet sein. Stellen, an denen der Quellcode am häufigsten geändert werden musste, sind Anhaltspunkte dafür, wo er am ehesten korrigiert werden muss.
Fazit
Gründe für technische Schulden sind vielfältig, etwa ein schlecht geschriebener Code, der mehrmals überarbeitet werden muss oder die Unachtsamkeit während eines Prozesses. Trotz der negativen Assoziation können sie dennoch durchaus positiv sein, da sie den Entstehungsprozess mit weiteren Learnings bereichern können. Neben den technischen Schulden muss ein Unternehmen auch die Mitarbeiter:innen und das zugehörige Team gut beobachten. Die Motivation und Produktivität hängt nämlich mit der Fehleranzahl im laufenden Prozess zusammen. Das Team stimmt darüber ab und trifft wichtige Entscheidungen, wie in solch einer Situation reagiert werden soll. Sie müssen schnell, flexibel und zuverlässig handeln. Störungen und die Entstehung der technischen Schulden müssen früh erkannt werden, damit sie künftig keine reale Gefahr für das gesamte Projekt und Unternehmen werden. Ein agiler Ansatz ist dabei von Vorteil, denn er schafft es, Teams so zu strukturieren, dass an allen Enden schnell reagiert werden kann und jedes Teammitglied sein eigener Experte ist. Entscheidungen müssen keine weitere Absprache durchlaufen. Scrum und Kanban können eine hilfreiche Methode sein, um Stakeholdern bewusst zu machen, dass technische Schulden auch einen positiven Einfluss haben können.
