Interview
16.04.2019, 09:03 Uhr
Je später ich sie zahle, desto teurer wird es.
Technische Schuld lässt sich meistern. Wie das geht, zeigt Michael Kaufmann in seiner Session auf der Developer Week. Im Interview erklärt er den Begriff.
(Quelle: Michael Kaufmann)
Der Begriff der Technischen Schuld wirkt auf den ersten Blick ziemlich sperrig: Da entsteht mit Herzblut, Know-how und Fleiß neue Software und gleichzeitig machen einem die Theoretiker das mit diesem Begriff madig. Man lade Schuld auf sich. Wer sich hier an Erbsünde und Ablasshandel erinnert sieht, hat vollstes Verständnis. Was es genau mit der Technischen Schuld auf sich hat und dass der Begriff ziemlich gut gewählt ist, zeigt sich im Interview mit Michael Kaufmann, der auf der Developer Week 2019 eine Session mit dem Thema Technische Schulden meistern – mit NDepend, Azure DevOps und SonarQube ein Kinderspiel (25. Juni 2019, 17.00 Uhr) hält.
Michael, die bringst in deiner Session den Begriff der technischen Schuld auf. Was genau verstehst du darunter?
In der Softwareentwicklung gibt es sichtbare Eigenschaften, die einen positiven Wert haben. Diese nennt man Features. Haben sie einen negativen Wert, dann spricht man von Bugs. Es gibt aber auch nicht sichtbare Dinge, die einen Wert aufweisen. Das sind zum Beispiel Refactorings, Updates auf neuere Plattformen und so weiter. Wenn diese Dinge einen negativen Wert haben, dann spricht man von technischen Schulden. Schulden, da sie irgendwann zurückgezahlt werden müssen.
Kannst du ein Beispiel dazu geben?
Ein klassisches Beispiel ist technische Dokumentation. Aber auch Workarounds, fehlende Testabdeckung und eine schlechte Architektur sind technische Schulden.
Bei Schuld fällt mir sofort der Begriff „Sühne“ ein. Wo muss man denn für die technische Schuld büßen?
Technische Schuld ist nichts Schlechtes. Um perfekten Code zu schreiben, würde man theoretisch unendlich viel Zeit benötigen. Es ist also immer eine Abwägung zwischen Zeit und Nachhaltigkeit. Wird die Schuld aber zu groß – wenn man also quasi überschuldet ist – erwächst ein großes Problem. Dann bekommt man nichts mehr geliefert, weil jede Änderung extrem aufwändig ist. Es gibt viele Systeme, die quasi insolvent geworden sind.
Wie kann man denn dafür sorgen, dass die Schuld erst gar nicht so groß wird? Gibt es einen Ablasshandel?
Das wichtigste ist die Schuld erst einmal anzuerkennen. Technische Schuld ist häufig ja die große Unbekannte. Dann muss man versuchen die Schuld zu qualifizieren und zu messen. Die Schuld wird dann in einem Korridor gehalten, der eine optimale Geschwindigkeit ermöglicht. Die Schuld sollte dabei nie diesen Korridor verlassen – oder eben ganz bewusst mit der Konsequenz, dass danach einen oder zwei Sprints nur Schulden abgebaut und keine Features geliefert werden. Mit den technischen Schulden ist es wie mit den Schulden auf der Bank: Je später ich sie begleiche, desto teurer sind sie.
