10 Tipps zum Umgang mit technischen Schulden
Technische Schulden (engl.: «Technical Debt») sind die Kosten, die in Zukunft entstehen, wenn digitale Produkte mit einer sehr kurzen Time-to-Market, aber mit einer nicht perfekten Codebase entwickelt werden. Wie Sie das Gleichgewicht zwischen geschäftlichen Zielen und eine nachhaltigen Wartung halten und Ihre technischen Schulden in Schach halten.
Wie einen Kredit bei der Bank auch, müssen Sie technische Schulden irgendwann zurückzahlen und je länger Sie dies nicht tun, desto teurer wird es. Doch im Vorhinein jede Zeile Code fehlerfrei fertigzustellen und die Architektur für jedes Zukunftsszenario zu wappnen, ist auch nicht die Lösung. In der Praxis sind technische Schulden unumgänglich, denn mit jedem Tag, an dem Sie länger an den Details Ihrer Software basteln, verpassen Sie die Chance auf sofortiges Feedback vom Markt. Und nicht nur das: Sie können Ihr Produkt erst viel später verkaufen und verdienen kein Geld, um Ihre Rechnungen zu bezahlen. Sie sehen, es ist ein Dilemma. Was also tun?
Das Wichtigste ist, sich den technischen Schulden bewusst zu sein und gezielt festzulegen, wie viel davon ein Projekt verträgt, um zu funktionieren. Sehen Sie sie als Teil Ihrer Strategie und seien Sie sich über die Konsequenzen im Klaren. Wenn Sie die in Zukunft benötigten Ressourcen für Refactoring von Anfang an mit einkalkulieren, wird es Ihnen wesentlich leichter fallen, den Schuldenberg abzubauen.
Die Sache mit der agilen Softwareentwicklung
Nicht umsonst streben viele Agenturen, auch mindnow, nach Agilität, denn Software entwickelt sich ständig weiter. Product Owner kommen mit neuen Funktionen, Teammitglieder bringen ihre Ideen ein, die Infrastruktur muss skaliert werden und die Marktanforderungen ändern sich sowieso. Das ist völlig normal.
Stellen Sie sich eine Web-App vor, mit E-Mail- und Passwort-Login mit einer einzigen personalisierten Seite. Knapp ein Jahr später möchten User vielleicht eine mobile App mit einem Apple-Login und einem integrierten Loyalitätsprogramm. Zeiten ändern sich. User und deren Bedürfnisse ändern sich. Deshalb muss sich auch die Software ändern!
Was oft unterschätzt wird, ist, dass Software mit immer mehr Features und Anpassungen immer komplexer und schwieriger zu warten wird. Wird dies viel schwieriger als ursprünglich angenommen, werden technische Schulden tatsächlich zum Problem.
Technische Schulden sind immer da und wachsen ständig an – es sei denn, Sie setzen proaktiv Schritte dagegen.
Was also tun? Hier sind meine besten Tipps und Tricks zum Umgang mit technischen Schulden aus meiner Erfahrung als CTO und Leiter von Produkt-Teams:
# 1: Ein guter Anfang
Spätestens, wenn Sie feststellen, dass Ihre technischen Schulden schneller steigen als gedacht, sollten Sie auf die Stop-Taste drücken und nach den Ursachen suchen. Oft liegt es an Problemen in der Codebase. Am besten Sie fangen hier zu suchen an:
Warnungen und veraltete Pakete
Code ohne Dokumentation
Code mit hoher zyklomatischer Komplexität (d. h. eine hohe Anzahl linear unabhängiger Pfade)
Module mit einem hohen Grad an Change Coupling (d. h. Module, die bei Änderungen weitere Änderungen in anderen Modulen verlangen)
# 2: Verwenden Sie Tools zur Visualisierung
Es gibt tolle Möglichkeiten, um sich einen Überblick zu verschaffen, zum Beispiel CodeScene. Das Tool ist eine Komplettlösung zur Analyse der Codebase. Es zeigt versteckte Risiken auf und hilft bei der Auswahl der richtigen Features für das Refactoring. Spezial-Tipp: Führen Sie kleine Schritte durch, anstatt das gesamte Projekt auf einmal vollständig zu durchleuchten. Der Schlüssel zum Erfolg liegt in der Regelmässigkeit über das ganze Jahr hinweg.
Eine Visualisierung von CodeScene: Jeder Kreis stellt ein Modul dar. Je grösser der Kreis, desto komplexer. Je kräftiger die Farbe, desto mehr Developer arbeiten daran.
# 3: Sensibilisierung von Agenturen und Kunden
Neben all den Änderungen, die mit neuen Usern und Marktanforderungen einhergehen, erlebe ich auch öfters Anfragen zu Features wie «der CEO möchte das und es muss bis morgen fertig sein». Vielleicht kommt Ihnen so etwas auch bekannt vor. Natürlich möchte man als Agentur jeden Kundenwunsch erfüllen. Doch wenn das gewünschte Feature zu hastig entwickelt wird, ist es schwierig, die API entsprechend zu erweitern. Das Ergebnis: Technische Schulden und langfristig höhere Kosten.
Ich sehe es als Aufgabe von Agenturen, Kunden die zukünftigen Kosten zu erklären. Hinter einem kurzfristigen Gewinn können sich langfristig zusätzliche Kosten verbergen. Wird dies jedoch klar, fällt es dem CEO sicherlich leichter zu verstehen, dass das Überspringen von Tests, Architektur, Dokumentation und Qualitätssicherung vielleicht doch nicht die beste Idee ist. Im besten Fall sind Kunden sogar dankbar dafür, wenn sie von ihrer Agentur darauf aufmerksam gemacht werden, wenn eine vermeintlich tolle Idee in Zukunft viele extra Stunden und zusätzliche Kosten verursachen könnte.
# 4: Definieren Sie einen guten Prozess
Stellen Sie sicher, dass Ihr Development-Prozess erstklassig ist. Formulieren Sie neben einer Einschätzung des Aufwands auch die Anforderungen im Detail. Halten Sie das ganze Team am Laufenden und stellen Sie sicher, dass Systeme vorhanden sind, die Verantwortlichkeiten der einzelnen Mitarbeitenden genau festlegen. Definieren Sie nicht nur, wer an was arbeitet, sondern auch wie. Ein gut durchdachter Prozess vermeidet Architekturprobleme und nicht testbaren Code. Auch wenn es sich am Anfang wie mehr Arbeit anfühlt – es zahlt sich absolut aus.
# 5: Alter Code, der funktioniert, ist eine gute Sache
Developern, die neu im Unternehmen sind, kommt beim ersten Blick auf die Codebase oft der Gedanke «Oh, das ist Legacy-Code! Der muss neu geschrieben werden, ich denke ich kann ihn verbessern!» Diese Art von Fehlinterpretation kommt tatsächlich öfters vor. Dabei ist alter Code etwas durchaus Positives. Warum? Aus einem ganz einfachen Grund: Nur guter Code wird überhaupt erst alt, während schlechter Code ständig überarbeitet wird. Alter Code, der über Jahre gleich geblieben ist, macht wahrscheinlich genau das, was er soll. Wenn etwas funktioniert, handelt es sich dabei nicht um technische Schulden, sondern schlicht um eine Codebase, die Sie so lassen sollten.
# 6: Technische Schulden nicht mit normalen Fehlern verwechseln
Selbst die talentiertesten Developer sind auch nur Menschen und können Fehler machen. Das führt aber nicht unbedingt gleich zu technischen Schulden. Solche entstehen, wenn absichtlich eine begrenzte Lösung entwickelt wird, anstatt gleich alles sorgfältig zu programmieren. Gewöhnliche technische Fehler, die durch eine falsche Entscheidung oder einen missglückten Versuch passiert sind, sind etwas ganz anderes. Zwar sollten Sie menschliche Fehler besser in das Projekt einplanen, doch das hat dies nichts mit einer schnelleren Time-to-Market zu tun und gehört in eine andere Schublade.
# 7: Machen Sie eine Release-Checkliste
Wann ist ein Feature wirklich fertig? Ich würde sagen, wenn alles so funktioniert, wie es in Auftrag gegeben wurde und wenn alles so funktioniert, wie es in der Release-Checkliste definiert wurde. Letztere ist dabei noch etwas gründlicher und enthält auch wichtige Punkte wie zum Beispiel:
Hat jede Funktion mindestens X Unit-Tests?
Wurde der Code von mindestens X Entwicklern überprüft?
Ist jede Funktion gut dokumentiert?
Die Funktionen einer Software oder eines digitalen Produkts müssen nicht nur aus geschäftlicher Sicht, sondern auch aus jener des Developments tiptop sein.
# 8: Ordentliche Dokumentation ist das A und O
Dokumentation ist extrem wichtig, auch wenn es oft schwierig ist, Developer dazu zu motivieren. Die Arbeit am Produkt selbst ist natürlich spannender als dessen Dokumentation und einige Developer verlieren das Feuer, um nach der Fertigstellung einer Funktion weiter daran zu arbeiten. Aus diesem Grund ist ein strenger Prozess für eine ordentliche Dokumentation ratsam.
Sorgen Sie neben der Dokumentation aud dafür, dass der Bus-Faktor des Teams größer als 1 ist. Stellen Sie sich nur vor, ein Developer ist von einem Tag zum anderen fort – und somit alles undokumentierte Wissen. Plötzliche unvorhergesehene Ereignisse wie ein Jobangebot annehmen, in eine andere Stadt ziehen oder – hoffentlich nicht – von einem Bus überfahren werden, können passieren. Mit einer guten Dokumentation sind solche Ereignisse weit weniger fatal für den Erfolg des Projekts.
# 9: Planen Sie Ressourcen für die Lösung von Problemen
Product Owner möchten die Geschwindigkeit des Teams während des Sprints so hoch wie möglich halten und das ist verständlich. Trotzdem müssen sie auch genügend Zeit für Altlasten einplanen. Neue Features allein machen keinen Release – dazu gehört noch eine Reihe an Verbesserungen an der Codebase, die genau so wichtig sind.
Die Lösung von Problemen wie Refactoring, Testing und Dokumentation erfordert Ressourcen und diese wollen gut geplant sein. Ich empfehle, dafür einen eigenen Tag in Ihrem Projektmanagement-Tool zu erstellen (mein Favorit ist Linear.app). So sind Probleme, die es noch zu lösen gilt, für alle gut sichtbar und bleiben in Erinnerung. Liegt der Fokus der Sprints auf der Geschwindigkeit allein, nehmen technischen Schulden zu und das gesamte Projekt verlangsamt sich.
# 10: Tracken Sie Metriken im Laufe der Zeit
Ich bestimme normalerweise nicht im Detail, welche Metriken bezüglich des Codes wann getrackt werden. Developer tendieren dazu, dann genau diese Metriken zu optimieren und sich selbst zu versteifen. Stattdessen stelle ich sicher, dass das Team weiss, dass im Laufe der Zeit folgendes begutachtet wird:
Wie viele neue Fehler hängen mit den neuen Features im Vergleich zu den alten Features zusammen?
Wer ist für den meisten Code verantwortlich?
Wie sieht es aus mit Komplexität und Code Coupling? (Siehe Tipp 1)
Ist das Wissen richtig im Team verteilt? (Dokumentation & Bus-Faktor, siehe Tipp 8)
Less than perfect code is fine as long as you know where you stand
Technical debt is not bad in all respects. Imagine you meticulously follow all the tips and write the perfect code without any error. You may work on it for years, and in the meantime, your competition has launched an even better solution, even though their code was much worse than yours when you entered the market.
Getting immediate feedback from the market is not only valuable in itself, but also well worth the technical debt. Since conditions change quickly, it's wise to release an alpha version as early as possible, as long as you remember that this step comes with fixing problems in the future. However, if you plan accordingly and follow my ten tips, you'll definitely keep your technical debt under control.
