Die moralische Dimension technischer Schulden

Tue, 14 Apr 2026 00:00:00 +0100

Was sind technische Schulden
#

In meinem vorherigen Artikel zum Thema Technische Schulden gehe detailliert darauf ein, was technische Schulden sind, wie sie entstehen, wie man sie erkennt und wie man sie verhindern bzw. verantwortungsvoll damit umgehen kann.

Einstieg - Das Erbe der anderen
#

Der erste Tag mit einer neuen Codebase ist immer ein bisschen wie das Auspacken einer Erbschaft. Man weiß nicht genau, was einen erwartet, doch man hofft auf sauberen Code und gute Dokumentation. Doch was man manchmal vorfindet ist das genaue Gegenteil.

Nun zu einem realen Vorfall, wie ich ihn in meiner Zeit als Freiberuflicher Entwickler erlebt habe.

Die erste Aufgabe klang simpel: einen bestehenden Bug fixen.

Nachdem ich etwa vier Stunden gebraucht hatte, um das Projekt zu finden, denn es lag nicht auf dem firmeninternen Gitlab Server, sondern auf dem Rechner des ehemaligen Kollegen, öffnete ich die Datei, die ich für “zuständig” hielt.

Was ich vorfand waren dreitausend Zeilen Code, kein Kommentar, keine Struktur, die diesen Namen verdient hätte.

Stattdessen Methoden, die sich über Hunderte von Zeilen erstreckten und alles auf einmal taten: Datenbankzugriffe, Businesslogik, UI-Rendering, irgendwo dazwischen ein paar Magic Numbers, die niemand mehr erklären konnte.

Der eigentliche Bug war schnell behoben, doch ihn zu lokalisieren hat zwei Tage gedauert.

Nachlässigkeit war der ausschlaggebende Punkt und nicht technische Komplexität. Wegen einer Haltung, die ich später in diesem Projekt immer wieder antreffen würde: Versionierung? Beiwerk. Formatierung? Beiwerk. Dokumentation? Beiwerk.

Was dabei übersehen wurde? Meine Zeit ist kein Beiwerk.

Technische Schulden neu definiert
#

Der Begriff stammt von Ward Cunningham, einem der Mitautoren des Agilen Manifests. Er prägte ihn in den frühen 1990ern und meinte damit ursprünglich etwas Pragmatisches: Manchmal ist es sinnvoll, eine nicht-optimale Lösung zu wählen, um schnell voranzukommen. So wie man einen Kredit aufnimmt, um heute investieren zu können und den man morgen zurückzahlt.

Der entscheidende Teil dieses Bildes wird heute gerne vergessen:
Schulden müssen zurückgezahlt werden. Mit Zinsen.

Wer einen Kredit aufnimmt und ihn ignoriert, hat in erster Linie ein Charakterproblem und erst dann entsteht auch ein Finanzproblem.

Dasselbe gilt für Code. Technische Schulden, die bewusst aufgenommen und dokumentiert werden, um später getilgt zu werden, sind ein legitimes Werkzeug und manchmal sogar unverzichtbar.
Technische Schulden, die aus Bequemlichkeit entstehen, still wachsen und still weitergereicht werden, sind etwas ganz anderes.

Und sie wachsen immer, das ist das Heimtückische an ihnen.

Jede neue Funktion, die auf einem schlechten Fundament aufbaut, macht das Fundament instabiler. Jede Abkürzung, die heute genommen wird, verengt den Korridor für morgen. Was als kleine Unordnung beginnt, wird zum Monolith, den niemand mehr anfassen will – weil niemand mehr versteht, was passiert, wenn man es tut. Der Zinseszins schlägt zu: Die Schulden wachsen nicht linear. Sie wachsen exponentiell.

Aber es gibt noch eine Dimension, die in dieser Finanzbuchhaltung fehlt. In der realen Welt zahlt derjenige die Zinsen, der den Kredit aufgenommen hat. Bei technischen Schulden zahlen oft andere: der Kollege, der den Code drei Jahre später debuggt. Die Entwicklerin, die eine neue Funktion einbauen soll und erst mal Wochen damit verbringt zu verstehen, was überhaupt da ist. Das Unternehmen, das Kunden verliert, weil ein System unter seiner eigenen Last zusammenbricht.

Technische Schulden sind keine abstrakte Metrik in einem Qualitätsbericht. Sie sind konkrete Lebenszeit – die von anderen Menschen. Zeit, die sie nicht wiederbekommen.

Die drei Verantwortlichkeiten
#

Die, die nach dir kommen
#

Stell dir vor, du ziehst in eine neue Wohnung. Der Vormieter hat die Wände mit Löchern übersät, Kabel lose verlegt, einen Wasserschaden hinter dem Schrank versteckt und beim Auszug einfach zugemacht. Du weißt nicht, was hinter den Wänden steckt, bis es tropft.

Genau so fühlt es sich manchmal an, fremden Code zu erben.

Das Schlimmste daran ist nicht die Arbeit, es ist die Erkenntnis, dass jemand das gewusst hat. Dass jemand diese Entscheidungen getroffen, diese Abkürzungen genommen, diese Verwahrlosung hinterlassen hat – und dann gegangen ist. Ohne ein Wort, ohne einen Kommentar, ohne den Mut, sich zu seinem eigenen Code zu bekennen.

Hinter jedem chaotischen Repository steckt ein Mensch, der einen anderen Menschen um dessen Zeit gebracht hat. Nicht mit Absicht, vielleicht. Aber Fahrlässigkeit ist keine Entschuldigung – sie ist eine Entscheidung, die man nicht bewusst getroffen hat.

Der Kollege, der heute deinen Murks debuggt, hat Familie, Hobbys, und allgemein Dinge, die er lieber täte, als in dreitausend Zeilen ungekennzeichnetem Code nach einer Race Condition zu suchen, die du vor drei Jahren eingebaut hast, weil du keine Zeit hattest, es richtig zu machen. Diese Stunden bekommt er nicht wieder zurück, die Energie, die er in das Verstehen steckt, was eigentlich da ist, fehlt ihm für das, was sein sollte: neue Dinge bauen, Probleme lösen, wachsen, Innovation vorantreiben.

Schlechter Code ist oft kein technisches Problem, sondern allzu häufig eine Geringschätzung der Zeit anderer.

Die, die deine Software benutzen
#

Der Nutzer sieht keinen Code. Er sieht ein Formular, das sich nicht abschicken lässt. Eine App, die abstürzt. Daten, die verloren gehen. Eine Fehlermeldung, die er nicht versteht und die niemand vorgesehen hat zu erklären.

Was er nicht sieht: dass sein Ärger, sein Datenverlust, seine Frustration die direkte Konsequenz einer Entscheidung ist, die jemand in einem Büro getroffen hat – still, unsichtbar, für ihn folgenlos. Sicherheitslücken entstehen nicht aus dem Nichts. Sie entstehen, wenn jemand entscheidet, dass Validierung heute keine Priorität hat. Datenverlust passiert nicht einfach. Er wird vorbereitet – durch Systeme, die niemand mehr versteht, und die deshalb niemand mehr zuverlässig warten kann.

Der Nutzer zahlt die Rechnung, ohne es zu wissen und ohne gefragt worden zu sein.

Das Unternehmen
#

Hier wird es nüchterner – aber nicht weniger ernst.

Technische Schulden sind ein wirtschaftliches Risiko, das in den meisten Roadmaps nicht auftaucht. Jede neue Funktion, die auf maroden Fundamenten gebaut wird, kostet mehr als geplant – weil ein Teil des Aufwands immer darin besteht, das Bestehende nicht zum Einsturz zu bringen. Wartung wird teurer. Onboarding neuer Entwickler dauert länger. Experimente, die Wettbewerber in zwei Wochen umsetzen, dauern sechs Monate – weil das System keinen Spielraum mehr hat.

Unternehmen, die Qualität systematisch als verzichtbar behandeln, kaufen sich kurzfristig Geschwindigkeit und bezahlen sie langfristig mit Handlungsunfähigkeit.

Das unbequeme Geständnis
#

Es wäre einfach, hier aufzuhören und zu behaupten:
Wer schlechten Code schreibt, ist ein schlechter Mensch. Fertig.

Ganz so leicht ist es aber nicht immer, denn die Wahrheit ist oft kompliziert und unbequem.

Technische Schulden entstehen nicht immer aus Faulheit oder Gleichgültigkeit, manchmal entstehen sie aus echtem Druck. Zum Beispiel aus Deadlines, die nicht verhandelbar waren, aus Ressourcen, die nicht vorhanden waren oder aus dem Wissen, dass eine unvollkommene Lösung, die heute läuft, besser ist als eine perfekte, die in drei Monaten fertig wird, dann aber vielleicht zu spät kommt.

Perfekter Code ist eine Illusion. Wer das Gegenteil behauptet, hat entweder noch nie unter echtem Druck gearbeitet oder lügt.

Der entscheidende Unterschied liegt nicht darin, ob Schulden entstehen oder nicht, er liegt darin, wie sie entstehen und mit ihnen umgegangen wird.

Es gibt technische Schulden, die man bewusst aufnimmt. Man bespricht es im Team, dokumentiert die Entscheidung, hält fest, warum diese Abkürzung heute sinnvoll ist und was es braucht, sie später zu tilgen. Das ist kein Versagen – das ist Pragmatismus mit Verantwortungsbewusstsein. Ein Kredit, den man kennt und plant zurückzuzahlen.

Und dann gibt es die andere Art. Die stillen Schulden. Die, die entstehen, weil jemand gehofft hat, dass es schon niemand merken wird. Die, die nicht dokumentiert werden, weil Dokumentation ja “Beiwerk” ist. Die, die still in den nächsten Sprint wandern, und den übernächsten, bis sie so tief im System vergraben sind, dass niemand mehr weiß, was sie eigentlich sind – nur noch, dass man sie besser nicht anfasst.

Der Unterschied zwischen diesen beiden Arten ist ein moralischer, kein technischer.

Wir nehmen diese Schuld auf, weil wir jetzt liefern müssen – und wir werden sie tilgen ist eine Aussage, die Respekt verdient.

Wird schon niemand merken ist keine Entscheidung. Es ist eine Kapitulation.

Management und die Kultur der Eile
#

Es gibt eine bequeme Ausrede, die sich in Entwicklerkreisen hartnäckig hält: Das Management ist schuld. Die Roadmap lässt keinen Raum für Refactoring, die Deadlines sind unrealistisch oder der Druck kommt von oben und wir unten sind die Leidtragenden.

Wie an fast jeder Geschichte ist auch an dieser etwas Wahres dran.

Organisationen, die Qualität systematisch als verzichtbar behandeln, schaffen Strukturen, in denen technische Schulden keine Ausnahme sind, sondern der Standard. Wenn Geschwindigkeit das einzige Maß für Erfolg ist, wenn jedes Sprint-Review nur nach abgeschlossenen Tickets fragt und nie nach dem Zustand des Fundaments, dann sendet das eine klare Botschaft: Nur Geschwindigkeit zählt, alles andere ist egal. So eine Kultur schafft langfristig kein festes Fundament für Fortschritt.

Aber diese Geschichte hat einen gefährlichen blinden Fleck: Sie macht Entwickler zu passiven Opfern, doch das sind sie nicht, zumindest nicht zwangsläufig.

Die unbequeme Wahrheit ist, wer schweigt, macht mit.

Wenn schlechte Entscheidungen nicht benannt werden, wachsen sie ungestört weiter. Wenn technische Schulden in keinem Meeting auftauchen, weil niemand sie auf die Agenda setzt, existieren sie für das Management schlicht nicht. Wenn Entwickler unter sich bleiben mit dem Wissen, dass ein System marode ist und dieses Wissen nie nach oben tragen, dann tragen sie Mitverantwortung für das, was daraus wird.

Das Management kann keine informierten Entscheidungen über Dinge treffen, von denen es nichts weiß. Das ist keine Entschuldigung für schlechte Führung, aber es ist eine Erklärung dafür, warum Schweigen keine neutrale Haltung ist.

Die Kultur der Eile entsteht selten durch eine einzige Entscheidung, oft entsteht sie durch hundert kleine Momente, in denen jemand gedacht hat: Ich sage es nächstes Mal. Das ist nicht mein Kampf. Es wird schon gutgehen. Und jedes Mal, wenn jemand so denkt, geht ein kleines Bisschen Information verloren.

Die Stimme erheben – Verantwortung annehmen
#

Verantwortung ist nichts Abstraktes, es zeigt sich in sehr konkreten Dingen.

Code-Reviews sind eine der wenigen Stellen im Entwicklungsprozess, an denen Qualität kollektiv verhandelt wird. Wer ein Review durchklickt, weil er keine Zeit hat oder keinen Konflikt will, verzichtet auf diese Chance. Wer ehrliches Feedback gibt – konstruktiv, respektvoll, aber klar – investiert in das Fundament, auf dem alle weiterarbeiten müssen. Das zeigt, dass Code-Reviews nicht als reiner Formalismus behandelt werden dürfen.

Schulden sichtbar machen ist keine Schwäche oder unnötiges nörgeln, sondern Professionalität. Ein Arzt, der einen Befund verschweigt, um den Patienten nicht zu beunruhigen, handelt nicht fürsorglich, sondern fahrlässig. Dasselbe gilt für Entwickler, die wissen, dass ein System instabil ist und dieses Wissen für sich behalten. Technische Schulden gehören dokumentiert, benannt, in Backlogs aufgenommen, aber definitv nicht versteckt.

Entwickler müssen auch lernen “Nein” zu sagen. Das ist nicht bequem aber sehr wichtig. Nicht immer ist ein Nein möglich und nicht jeden Kampf kann man gewinnen, aber wer nie Nein sagt, wer jedem Druck wortlos nachgibt und jede unrealistische Deadline kommentarlos akzeptiert, der hat aufgehört, Verantwortung zu tragen.

Und besonders an alle, die gerade am Anfang stehen: Ihr lernt gerade nicht nur Programmieren. Ihr lernt, wie ihr arbeiten wollt, welche Standards ihr setzt, welche Kompromisse ihr eingeht und welche nicht. Ihr habt die Chance, Gewohnheiten zu entwickeln, die euch und alle, die nach euch kommen, prägen werden.

Also erhebt eure Stimme, wenn ihr Mängel erkennt und steht zu euren Entscheidungen, auch wenn es mal unbequem wird.

Der Weckruf (Schluss)
#

Jede Zeile Code, die du schreibst, ist eine Entscheidung.

Es ist sowohl eine technische, als auch eine moralische.
Du entscheidest, wie viel dir die Zeit derjenigen wert ist, die nach dir kommen.
Du entscheidest, ob du ein Fundament baust oder eine Falle.
Du entscheidest, ob du Verantwortung trägst oder weiterschiebst.

Das klingt abstrakt und schwer, aber tatsächlich kann man mit kleinen Entscheidungen viel Bewirken.

Hinterlässt du eine Methode mit zweihundert Zeilen, obwohl du weißt, dass sie zu lang ist und sagst, du hattest keine Zeit?
Lässt du einen Kommentar weg, weil er dir gerade trivial erscheint und vergisst, dass er für jemand anderen alles bedeuten könnte?
Begräbst du eine technische Schuld still, anstatt sie zu benennen, weil es so bequemer ist?

Wenn du diese oder ähnliche Fragen klar mit Nein beantworten kannst, bist nicht Teil des Problems, sondern Teil der Lösung.

Nimm dir zehn Minuten Zeit, um etwas zu erklären, das du gerade verstanden hast, sag im Review, was du wirklich denkst, steh in einem Meeting auf und sag: Das geht so nicht, ich schlage vor wir machen das so…

Du weißt jetzt, was technische Schulden sind, wer sie bezahlt, wie sie entstehen und warum Schweigen keine neutrale Haltung ist. Du weißt, dass perfekter Code eine Illusion ist, aber bewusste, dokumentierte, ehrliche Arbeit keine.

Was du nun daraus machst, liegt ganz bei dir.

Und denk immer daran: Irgendwo sitzt gerade jemand an deinem Code und fragt sich, wer das hinterlassen hat und warum.

Also schreibe deinen Code so, dass du guten Gewissens und mit Stolz sagen kannst: Das habe ich programmiert.

Zum Schluss möchte ich noch John Woods zitieren, der es etwas provokanter Ausdrückt, jedoch das gleiche meint:

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.

John Woods

Vorschaubild
#

freepik

Verantwortung on Devcartes

Die moralische Dimension technischer Schulden

Was sind technische Schulden #

Einstieg - Das Erbe der anderen #

Technische Schulden neu definiert #

Die drei Verantwortlichkeiten #

Die, die nach dir kommen #

Die, die deine Software benutzen #

Das Unternehmen #

Das unbequeme Geständnis #

Management und die Kultur der Eile #

Die Stimme erheben – Verantwortung annehmen #

Der Weckruf (Schluss) #

Vorschaubild #