Technische Schulden sind die Rechnung für jede Abkürzung

Gemeint ist nicht schlechter Code, sondern eine Wette auf später

Der Begriff stammt von Ward Cunningham aus dem Jahr 1992. Er hat die Abkürzung mit einem Kredit verglichen. Ihr nehmt euch heute Zeit heraus, die eigentlich in die Struktur gehört hätte, und zahlt sie später mit Zinsen zurück.

Das ist keine Nachlässigkeit. Oft ist es sogar die richtige Entscheidung. Wer vor dem ersten Kunden steht, braucht eine laufende Anwendung und kein sauberes Fundament. Zur Schuld wird die Abkürzung erst, wenn niemand mehr weiß, dass sie genommen wurde.

Genau da liegt der Unterschied zwischen der bewussten und der unbemerkten Abkürzung. Die bewusste steht fest, und ihr könnt sie einplanen und zurücknehmen. Die unbemerkte findet ihr erst, wenn eine Änderung an einer ganz anderen Stelle etwas kaputt macht.

Jede Abkürzung nimmt eine Regel aus dem System

Jede Anwendung trägt Regeln, die aus eurem Geschäft kommen. Ein Auftrag wird erst abgerechnet, wenn er abgenommen ist. Ein Kunde darf nicht zweimal angelegt werden. Solche Regeln muss die Software kennen, ob sie irgendwo festgehalten sind oder nicht.

Fehlt die Festlegung, liegt die Regel verteilt im Code. Sie steht an jeder Stelle, an der sie gerade gebraucht wurde. Beim ersten Mal kostet das nichts. Beim siebten Mal weiß niemand mehr, wo sie überall steht.

Von da an wird jede Änderung teurer als die davor. Das Ändern selbst wird nicht schwerer, das Nachsehen dauert länger. Eine neue Anforderung landet an sieben Stellen statt an einer, und jede davon kann etwas umwerfen.

In der Gestaltung ist dasselbe Muster längst bekannt. Eine Farbe, die an dreißig Stellen einzeln eingetragen wurde, lässt sich nicht mehr ändern. Ein System hält solche Entscheidungen an einer Stelle fest, damit eine Änderung genau dort ankommt. In der Software gilt das genauso, nur fällt es dort später auf.

Der Gegenentwurf ist unspektakulär. Die Regeln stehen fest, bevor gebaut wird, und zwar sichtbar und an einer Stelle. Wer sie nachlesen will, muss nicht im Quelltext suchen.

Bezahlt wird in Zeit, lange bevor es in Geld sichtbar wird

Der größere Teil der Rechnung entsteht nach dem Bau, und er taucht nirgends als Posten auf. Er steckt in Tagen, die jemand mit Suchen verbringt. Er steckt in Änderungen, die zweimal gemacht werden mussten, weil die erste Fassung an anderer Stelle etwas umgeworfen hat.

An vier Stellen fällt das im Alltag auf.

• Schätzungen werden unzuverlässig, weil niemand mehr sagt, was eine Änderung berührt
• Neue Leute brauchen Monate, bis sie etwas anfassen dürfen
• Aufgaben werden nach Risiko sortiert statt nach Nutzen
• Ein Teil des Teams repariert dauerhaft Folgen, statt Neues zu bauen

Keine dieser Stellen erscheint in einem Angebot, und trotzdem zahlt ihr sie jeden Monat. Irgendwann kippt das Verhältnis. Dann kostet eine Erweiterung mehr, als derselbe Teil neu gebaut kosten würde, und ihr bezahlt alles ein zweites Mal.

Woran ihr merkt, dass ihr schon weit rechts auf der Kurve steht

Kaum jemand entscheidet, dass ein System kippt. Es fällt daran auf, dass sich das Reden über die Arbeit ändert. Vier Anzeichen sind dabei verlässlich.

• Eine kleine Änderung löst eine große Diskussion aus
• Niemand kann abschätzen, was sie an anderer Stelle umwirft
• Neue Anforderungen dauern Wochen, wo sie früher Tage gedauert haben
• Wissen über das System steckt in einem einzigen Kopf

Trifft mehr als eines davon zu, kostet euch das Alte bereits mehr, als es euch bringt. Der Ausweg ist selten der komplette Neubau. Meistens steht am Anfang einer Software-Modernisierung eine Prüfung, die klärt, was bleibt und was ersetzt wird. Oft bleibt mehr stehen, als das Team selbst erwartet hat.

Was die Kurve flach hält

Ein Neubau allein flacht die Kurve nicht ab. Er verschiebt sie nur um ein paar Jahre nach hinten. Flach bleibt sie, wenn die Struktur eurem Geschäft folgt statt der Technik. Dann liegt eine Regel an einer Stelle, und eine neue Anforderung trifft genau diese Stelle.

Deshalb steht bei uns am Anfang ein Fachmodell und nicht der Code. Wir schreiben auf, welche Dinge es in eurem Geschäft gibt und was mit ihnen passieren darf. Zum Beispiel: Es gibt Kunden, Aufträge und Rechnungen, und ein Auftrag wird erst abgerechnet, wenn er abgenommen ist.

Aus diesem Modell entsteht die Struktur der Anwendung. In der Webentwicklung heißt das, dass eine Regel einen festen Ort hat, statt im Code verstreut zu liegen. Eine automatische Prüfung sagt euch vorher, ob eine Änderung etwas anderes bricht.

Am ersten Tag sehen zwei Anwendungen gleich fertig aus. Der Unterschied zeigt sich erst nach Jahren, wenn Änderungen immer noch ungefähr so lange dauern wie am Anfang. Genau diese gleichbleibende Dauer ist der Gegenwert, und sie lässt sich vorher nicht vorführen.

Sichtbar wird sie an der Aufteilung. Jeder Teil des Systems hat eine Aufgabe und eine Grenze. Wer etwas ändert, weiß danach, wie weit die Änderung reicht, und muss den Rest nicht prüfen.

Das gilt für ein neues Produkt genauso wie für eines, das schon ein paar Jahre trägt. Der Aufwand steckt dabei nicht im Bauen. Er steckt darin, die Regeln zu klären, bevor jemand sie im Code errät.