… ungeliebt und missverstanden. Doch eigentlich liegt darin ein großes Potenzial. Denn bei jedem Softwareprojekt lernen alle Beteiligten im Zeitverlauf immer mehr über die Materie. Man muss dafür sorgen, dass die Software das aktuelle Verständnis widerspiegelt (und die alten in Code gegossenen Annahmen korrigieren/anpassen). Und das ist möglich durch Abzahlen der technischen Schulden.
Der Begriff “Technische Schuld” [auch im Deutschen oft “Tech Debt” oder “technical debt” genannt] wird leider oft missverstanden.
Kurz und sehenswert ist das folgende Video vom Schöpfer des Begriffs: Ward Cunningham hat das erste Wiki entwickelt und das Manifest für Agile Softwareentwicklung (2) mitgeschrieben. In diesem Video (gehostet auf YouTube) erläutert er die Gedanken hinter dem Begriff “Tech Debt”. (1)
tl;dw video: Bei jedem Softwareprojekt lernen alle Beteiligten im Zeitverlauf immer mehr über die Materie. Man kann aber nicht einfach stur weitermachen und dabei versäumen, das Gelernte wieder zurück in die Programmierung zurückfließen zu lassen! Warum? Weil: Dann verhalte ich mich, wie jemand, der sich Geld bei der Bank leiht, aber denkt, dass er es nie zurückzahlen muss. Dann ist es wie bei einer dauerhaft überzogenen Kreditkarte: irgendwann geht alles Geld für die Zinszahlungen drauf und die Kaufkraft geht gegen null. Statt Neues zu entwickeln, muss ich um das Alte umständlich herumbauen. Aber: Wer statt Wegsehen seinen Kredit im Blick hat und die Raten immer wieder zurückzahlt, tappt nicht in diese Falle, also: Man muss dafür sorgen, dass die Software das aktuelle Verständnis widerspiegelt (und die alten in Code gegossenen Annahmen korrigieren/anpassen)… oder man wird kontinuierlich darüber stolpern.
Schimäre “Perfektion”
Bei Agilität dreht sich alles um schnelle Feedbackschleifen, diese dauern Stunden oder höchstens ein paar Tage. Die absichtliche Verlängerung dieser Schleifen auf der Suche nach der Schimäre der Perfektion zerstört Agilität. Die Kosten für solche Verzögerungen sind reale Kosten – finanzielle Kosten, echtes Geld. Sie übersteigen in der Regel die Entwicklungskosten um ein Vielfaches. Ein Release absichtlich zu verzögern, während (oder weil) man nach perfektem Wissen strebt, ist unverantwortlich. Das ist buchstäblich so teuer, dass es das Unternehmen zerstören kann.
Daher kommt auch der Begriff der “technischen Schulden”.
Wir releasen Code, um zu lernen…
Tech Debt basiert auf der sehr agilen Idee, dass es gut und essentiell ist, laufenden Code in die Hände der User:innen zu geben, weil wir Feedback erhalten wollen. Wir veröffentlichen wohl wissend minimal funktionalen Code – ohne Schnickschnack – um zu lernen. Denn das ist der beste Weg, um zu lernen. Wir wissen, dass er nicht alles kann. Das ist auch in Ordnung. Der Code, den wir in die freie Wildbahn entlassen, wird also per definitionem unperfekt sein. Nicht fehlerhaft, sondern unperfekt – das ist ein Unterschied. Wir wissen genau, dass unser Code teilweise unvollständig oder falsch sein wird; wir wissen nur nicht genau, was fehlt oder zu viel ist, oder was daran falsch ist. Das ist die technische Schuld.
Paradoxerweise führt der Tausch von Perfektion gegen schnelles Feedback in der Regel dazu, dass wir der “Perfektion” (oder zumindest einem “sehr gut”) schneller näher kommen. Indem wir Schulden machen und dann diese Schulden schnell abbezahlen. Indem wir durch Feedback lernen, was falsch ist, und dann auf Basis dieses Feedbacks handeln, kommen wir in kürzerer Zeit zu einem besseren Ergebnis.
Die Kreditkarte “Tech Debt”
Jeden Monat Tech Debt abbezahlen.
Technische Schulden entstehen ganz natürlich, wenn wir Code schreiben. Richtig gehandhabt, funktioniert das wie eine Kreditkarte. Man zahlt monatlich etwas ab. Wenn wir das nicht tun, steigt die Belastung so weit an, dass wir es nicht mehr zurückzahlen können. Wir werden unter den Zinszahlungen begraben. Im Agilen ist das Äquivalent zum Abzahlen der Karte das Refactoring, um jene Dinge einzubauen, die man durch das Release gelernt hat: Wenn wir etwas sehen, das nach dem heutigen Kenntnisstand nicht (mehr) richtig ist, beheben wir es. Wenn wir die Schulden nicht “abbezahlen” - also den schwer zu bearbeitenden Code nicht beseitigen, der nicht das tut, was unsere Benutzer brauchen -, werden wir unter den “Zinsen” begraben.
Der Schlüsselgedanke ist: Wir lernen immer bei der Arbeit dazu. Keine:r kann alles, was man wissen muss, im Voraus wissen.
Schulden entstehen, weil man Dinge nicht weiß oder (noch) nicht wissen kann. Sie fallen in die Kategorie, “damals war es eine gute Idee”. Sobald man etwas gelernt hat, zahlt man die Schulden ab. Um Ward Cunningham zu zitieren, der den Begriff der technischen Schulden erfunden hat: “[Das Team hat den Code geändert], damit es so aussieht, als hätten sie von Anfang an genau gewusst was zu tun ist.”
Technische Schulden entstehen auch, weil wir dazu neigen, nur das zu lernen, was nötig ist, um den Code zum Laufen zu bringen. Es ist Technische Schuld, wenn man erfährt, dass man eine neu erlernte Bibliothek nicht so verwendet, wie sie verwendet werden sollte. Das ist kein “Bug” oder Fehler – der Code funktioniert so, wie wir es erwarten, nur nicht so gut, wie er könnte. Das ist eine andere Art von Lernproblem. Das sollte man wie jede andere technische Schuld ebenfalls beheben.
Technische Schulden sind Code, der sich genau so verhält, wie wir es erwarten, aber unsere Erwartungen sind falsch.
Was ist mit Fehlern?
- Bugs sind Code, der sich nicht so verhält, wie Sie es erwarten.
- Technische Schulden sind Code, der sich exakt/genau so verhält, wie Sie es erwarten, aber unsere Erwartungen sind falsch.
- Technische Schulden haben nichts mit Bugs zu tun.
(Mehr zu den 3 Arten von Fehlern in der IT in unserem Artikel “Fehler vs. Erfahrungskultur”(3))
Erfahrung durch häufige Releases
Wir liefern den bestmöglichen Code, in Bezug auf das was wir aktuell wissen. Wir ignorieren niemals absichtlich Wissen darüber wie sich der Code verhalten soll, wenn dieses Wissen vorhanden ist. Der freigegebene Code ist (oder sollte es zumindest sein) ein qualitativ hochwertiger, vollständig getesteter Code, der keine bekannten Fehler aufweist. Er ist trotzdem falsch, weil wir nicht alles wissen. Und es gibt keine Möglichkeit, exakt zu wissen, weshalb er falsch ist. Man weiß nicht, was man nicht weiß. Man lernt, was falsch ist, indem man etwas veröffentlicht und Feedback dazu erhält, und indem man weiter Code schreibt und mehr Erfahrungen sammelt.
“Gleichzeitig die Qualität steigern und die Kosten senken durch Reduzieren von Verschwendung und Nacharbeit […]” – William Edwards Deming
Lasst uns das kurz wiederholen weil es wichtig ist: Bei einer Veröffentlichung sollte es keine bekannten Fehler geben, andere Fehler sollten sofort behoben werden, sobald sie auftauchen. Tech Debt ist kein schlampiger, schlecht geschriebener Code. Dafür gibt es niemals eine Entschuldigung. Schlampiger, schlecht geschriebener Code bremst einen so stark aus, dass Agilität unmöglich wird. Man kann sich nicht schnell genug bewegen, wenn man seinem Code nicht trauen kann. Die Vorstellung, schlampigen Code schreiben zu müssen, um schneller zu sein, ist ein kostspieliger Mythos (vgl. William Edward Demings Auffassung von Qualität (4)). Eine Fülle von Fehlern ist keine “technische Schuld”. Es ist Inkompetenz. Und das zerstört die Effektivität der Programmierer:innen.
Tech Debt begleichen oder “Nokia”
Außerdem: wenn man seine Schulden nicht so schnell wie möglich tilgt, wird das Unternehmen letztendlich begraben. Nokia ist unter der Last von technischen Schulden gestorben (eine technische Architektur, die es den Entwickler:innen nicht erlaubte, Änderungen schnell genug vorzunehmen). Technische Schulden führen dazu, dass die Entwicklungszeiten in Tagen gemessen werden. Agilität ist in einer solchen Umgebung nicht möglich. Das soll nicht heißen, dass alle technischen Schulden beseitigt werden müssen. Wenn die Schulden einen nicht daran hindern, agil zu arbeiten, kann es eine vernünftige Entscheidung sein, sie einfach in Ruhe zu lassen.
Technische Schulden nicht zu bezahlen ist nicht agil
Es ist also in Ordnung, etwas zu liefern, in vollem Bewusstsein, dass man mit der Zeit dazulernt und den Code überarbeiten muss, um das Gelernte zu nutzbar zu machen. Das ist eine grundlegende agile Denkweise. Das Nicht-Refactoring, also das Nicht-Bezahlen der Schulden, ist eine extreme Form der Dysfunktion. Es bremst zu sehr aus. Das ist nach keiner Definition nach agil.
Dieser Artikel über Technical Debt von Allen Holub erschien zuerst auf Englisch unter https://holub.com/technical-debt/. Er entspricht unserem Verständnis von Tech Debt und Erfahrungskultur, wir haben ihn durch Kommentare und Links ergänzt.
(1) Ward Cunningham https://en.wikipedia.org/wiki/Ward_Cunningham. (2) Manifest für Agile Softwareentwicklung http://agilemanifesto.org/. (3) Fehler nur machen oder auch daraus lernen https://blog.gs-9.com/posts/fehler-vs-erfahrungskultur/. (4) Demings Lehre zusammengefasst https://en.wikipedia.org/wiki/W._Edwards_Deming#Academic_contributions.
