Wahrscheinlich zucken bei diesem Ausspruch viele Leser zusammen und schütteln heftig mit dem Kopf. Wenn man sich aber genauer anschaut, wie diese Metapher eigentlich ursprünglich gemeint war, eröffnet das andere Perspektiven. Und man wird feststellen, dass der Begriff heute einfach ganz häufig nicht im ursprünglichen Sinn genutzt wird. Wenn wir diese neuen Perspektiven dann noch mit guten agilen Prinzipen kombinieren, dann machen technische Schulden durchaus Sinn – zumindest, wenn man die Metapher richtig anwendet.

Ward Cunningham, der den Ausdruck „technical debt“ geprägt hat, hat selbst in einem kurzen Video) erklärt, was er für ihn bedeutet. Wir sollten uns die Zeit nehmen, seine Punkte aus dem Video etwas näher zu betrachten:

It was important to me that we accumulate the learnings we did about the application over time by modifying the program to look as if it had been as if we had known what we're doing all along […] The explanation I gave to my boss, and this was financial software, was a financial analogy. I called it the debt metaphor and that said that if we fail to make our program align with what we then understood to be the proper way to think about our financial objects then we were going to continually stumble over that disagreement and that would slow us down which is like paying interest on a loan.

Hier beschreibt Ward sehr schön, warum er die Metapher der Schulden gewählt hat. Und er macht von Beginn an deutlich, dass diese Schulden nicht kostenlos sind. Wir müssen selbstverständlich Zinsen dafür bezahlen. Es steckt aber noch etwas anderes, sehr wichtiges in dieser Aussage: Ward geht davon aus, dass wir beim Entwickeln unserer Software dazulernen. Er geht davon aus, dass wir es nicht im ersten Anlauf so hinbekommen, wie es sein sollte. Und das liegt nicht an unserem Unvermögen, sondern an der Komplexität der Herausforderung. Um das schon mal vorwegzunehmen: im nicht komplexen Umfeld müssen wir meist keine technischen Schulden eingehen. Ist die Aufgabenstellung hingegen komplex, lohnt es sich häufig gar nicht, bereits vor der Umsetzung zu versuchen, bereits vor der Umsetzung alle wichtigen Informationen zu herauszufinden. Wir können durch einen frühen Start der Umsetzung schneller und einfacher zu den notwendigen Einsichten gelangen. Das wird im folgenden Zitat noch deutlicher:

With borrowed money you can do something sooner than you might otherwise but then until you pay back that money, you'll be paying interest. I thought borrowing money was a good idea. I thought that rushing software out the door to get some experience with it was a good idea.

Hier beschreibt er genau den Vorteil von technischen Schulden. Statt noch länger zu versuchen, mehr über konkrete Anforderungen, notwendige Datenstrukturen und Architektur oder Implementierungsoptionen herauszufinden, sollte man ab einem gewissen Punkt einfach mit der Umsetzung beginnen. Und das in dem vollen Bewusstsein, dass wir Entscheidungen später korrigieren müssen, wenn wir mehr gelernt haben. Also in dem vollen Bewusstsein, dass wir technische Schulden eingehen, die wir später zurückzahlen müssen. Wir erkaufen uns quasi Zeit mit unseren technischen Schulden, Zeit, in der wir früher Erfahrung mit unserem Code und unserem Produkt sammeln können.

But that of course you would eventually go back and as you learn things about that software you would repay that loan by refactoring the program to reflect your experience as you acquired it.

Hier kommt zum Ausdruck, dass der Metapher eine Grundannahme zugrunde liegt: Die Schulden müssen zurückbezahlt werden. Immer dann, wenn man eine neue Erkenntnis gewonnen hat, erhöhen sich die technischen Schulden. Und diese versuchen wir so zeitnah wie möglich zurückzuzahlen. Welche Auswirkungen es hat, wenn dies nicht geschieht, wird im nächsten Abschnitt beschrieben.

I think that there were plenty of cases where people would rush software out the door and learn things but never put that learning back into the program and that by analogy was borrowing money thinking that you never had to pay it back. Of course, if you do that, say with your credit card, eventually all your income goes to interest and your purchasing power goes to zero. By the same token if you develop a program for a long period of time by only adding features and never reorganizing it to reflect your understanding of those features then eventually that program simply does not contain any understanding in all efforts to work on it to take longer and longer. In other words, the interest is total, you'll make zero progress.

Hier wird die Genialität der Schulden-Metapher klar. Für die Schulden müssen wir Zinsen zahlen. In der Software sind das zusätzliche Aufwände, die wir haben, um mit diesen Dingen umzugehen, die nicht unserer aktuellen Vorstellung von der Ideallösung entsprechen. Das können Missverständnisse durch schlecht benannte Objekte sein, Fehler durch übersehene Auswirkungen von Änderungen, fehlende Dokumentation oder Testabdeckung usw. Diese Zinsen müssen von unserer Kapazität abgezogen werden, d.h. sie reduzieren unsere Möglichkeiten für unsere Anwender echten Mehrwert zu generieren. Die Zinslast beschränkt unseren Handlungsspielraum. Gleichzeitig besteht eine hohe Erwartungshaltung, schnell neue Features zu liefern, schließlich sind das unsere Stakeholder ja gewohnt. Um nun die Zinsen bedienen zu können und gleichzeitig noch Mehrwert zu liefern, nehmen wir neue Schulden auf, was dann wieder zu einer erhöhten Zinslast führt. Ein Teufelskreis, der bis zum Stillstand führen kann.

Soweit herrscht sicher großer Konsens über die Schulden-Metapher. Leider wird sie viel zu häufig als Synonym für schlechten Code missbraucht. Ward sagt hierzu im Video:

A lot of bloggers at least have explained the debt metaphor and confused it with the idea that you could write code poorly with the intention of doing a good job later and thinking that that was the primary source of debt.

Hier wird ganz klar, dass technische Schulden nicht als „Ausrede“ für schlechten Code missbraucht werden sollen.

I'm never in favour of writing code poorly. But I am in favour of writing code to reflect your current understanding of a problem even if that understanding is partial. You know, if you want to be able to go into debt that way by developing software that you don't completely understand, you're wise to make that software reflect your understanding as best you can so that when it does come time to refactor it's clear what you were thinking when you wrote it and making it easier to refactor it into what your current thinking is now. In other words, the whole debt metaphor, or let's say the ability to pay back debt and make the debt metaphor work for your advantage depends upon you writing code that is clean enough to be able to refactor as you come to understand your problem.

Damit nochmals verdeutlicht, dass technische Schulden einzugehen vollkommen OK ist. Wir müssen aber immer darauf achten, dass wir den Code so schreiben, dass er einfach verändert werden kann. Aber damit gilt auch, dass schlechter Code, der nur schwer verständlich und schlecht angepasst werden kann, nicht als technische Schulden gilt. Technische Schulden sind keine Ausrede für schlechten Code. Oder um in der Metapher zu bleiben: Wir dürfen nur dann Schulden eingehen, wenn wir die Voraussetzungen geschaffen haben, dass wir die Schulden einfach zurückzahlen können.

Nach diesem etwas ausführlichen Exkurs in die Gedanken hinter der Schulden-Metapher wollen wir uns nochmal kurz der Ausgangsthese zuwenden und diese mit den nun vorliegenden Einblicken beurteilen.

Technische Schulden sind kein Problem, sondern eine Lösung!

Technische Schulden sind nach dieser Lesart tatsächlich kein Problem, solange wir diese nur dann eingehen, wenn wir uns dadurch einen Vorteil verschaffen. Nur dann, wenn wir dadurch frühzeitig einen Mehrwert generieren, der höher ist als die Zinsen und die Tilgung. Einen Aspekt, wie wir uns durch technische Schulden Vorteile verschaffen können, habe ich beispielsweise in meinem Artikel zum Thema MVP beschrieben.

Zum Problem werden die technischen Schulden nur dann, wenn wir sie leichtfertig eingehen, ohne einen klaren Vorteil dadurch zu haben. Und natürlich auch dann, wenn wir diese Schulden zu lange mit uns herumschleppen. Dann wird es immer schwieriger, die Zinsen und Tilgung durch den erreichten Mehrwert zu kompensieren.

Nun interessiert mich aber eure Erfahrung mit technischen Schulden. Wie erlebt ihr das? Werden die als Ausrede für schlechten Code missbraucht? Ist transparent, wann ihr technische Schulden eingeht und warum? Gibt es einen Tilgungsplan für eure technische Schulden? Und natürlich: Seht ihr technische Schulden als Problem oder als Lösung an?

Lasst uns gerne auf LinkedIn diskutieren.