Technische Schulden vermeiden: Architektur-Entscheidungen im Festpreis-Projekt

Jedes Legacy-System war einmal ein neues System. Die Sonderfälle, Abkürzungen und "das machen wir später" - Entscheidungen, die eine spätere Ablösung so riskant und teuer machen, entstehen nicht durch Alter, sondern durch Entscheidungen am allerersten Tag des Projekts. Wenn du gerade eine neue Individualsoftware zum Festpreis beauftragst, ist genau jetzt der Zeitpunkt, an dem sich technische Schulden am günstigsten vermeiden lassen - nicht erst in drei Jahren, wenn eine Migration ansteht.

Was technische Schulden für dich als Auftraggeber bedeuten

Im Deutschen spricht man von "technischen Schulden", in Entwicklerkreisen oft vom englischen Originalbegriff "technical debt". Beide meinen dasselbe, und es lohnt sich, den englischen Begriff zu kennen, weil er in Angeboten, Tickets und Gesprächen mit internationalen Entwicklungsteams mindestens genauso häufig fällt wie die deutsche Übersetzung.

Technische Schulden sind keine rein technische Kategorie, die du getrost dem Entwicklungsteam überlassen kannst. Sie sind eine Kostenverschiebung: Eine Abkürzung, die heute Zeit spart, wird morgen zu einer teureren Änderung, einem instabileren System oder einer Abhängigkeit von genau der einen Person, die den Workaround verstanden hat. Der Unterschied zu einem klassischen Legacy-System ist der Zeitpunkt - hier entscheidest du, bevor die erste Zeile Code geschrieben ist, nicht danach, wenn die Ablösung ansteht. Was eine bereits gewachsene Altlast angeht und wie man sie sicher ablöst, behandelt der Artikel zu Legacy-System ablösen - dieser Beitrag hier ist das Gegenstück davor: wie du verhinderst, dass dein neues System in ein paar Jahren genau dort landet.

Die Kredit-Metapher stammt von Ward Cunningham, der den Begriff 1992 auf der OOPSLA-Konferenz prägte: "Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. [...] The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt." - auf Deutsch sinngemäß: Code das erste Mal auszuliefern ist wie ein Kredit. Eine kleine Schuld beschleunigt die Entwicklung, solange sie zeitnah durch eine Überarbeitung zurückgezahlt wird. Gefährlich wird es erst, wenn diese Rückzahlung ausbleibt - dann zahlt jede weitere Minute, die für nicht ganz passenden Code aufgewendet wird, auf die Zinsen dieser Schuld ein. Martin Fowler hat die Metapher später um das Bild der laufenden Zinsen ergänzt: "The extra effort that it takes to add new features is the interest paid on the debt." Genau diese Zinsen sind es, die du als Auftraggeber am Ende zahlst - in Form von langsameren Änderungen, höheren Folgekosten oder einem System, das niemand mehr gerne anfasst.

Den Technologie-Stack hinterfragen, bevor er festgelegt wird

Ein häufiger, stiller Fehler: Der Technologie-Stack wird nicht danach gewählt, was für dein Projekt langfristig sinnvoll ist, sondern danach, was der beauftragte Entwickler oder die Agentur gerade gut kann. Das ist nicht per se falsch, aber es lohnt sich, im Angebot konkret nachzufragen:

Wie groß ist die Entwickler-Community für dieses Framework oder diese Sprache - findest du in drei Jahren noch problemlos jemanden, der sich damit auskennt?
Wird der Stack aktiv weiterentwickelt und mit Sicherheitsupdates versorgt, oder handelt es sich um eine Nischentechnologie kurz vor dem End-of-Life?
Ist die Wahl mit deinem Projekt begründet oder mit der Präferenz des Entwicklers? Beides kann zusammenfallen, muss es aber nicht.

Ein Stack, den nur eine Person im Projektteam beherrscht, ist selbst dann ein Risiko, wenn er technisch hervorragend geeignet ist - siehe dazu auch den Abschnitt zur Dokumentation weiter unten.

Das Datenmodell: Teuer zu ändern, leicht zu unterschätzen

Manche Architekturentscheidungen lassen sich später mit überschaubarem Aufwand korrigieren. Das Datenmodell gehört selten dazu. Wenn du schon beim Projektstart weißt, dass mehrere Kunden, Mandanten oder Standorte das System nutzen werden, aber die erste Version "erstmal nur für uns" gebaut wird, ohne Mandantentrennung im Datenmodell vorzusehen, wird die spätere Nachrüstung oft teurer als der ursprüngliche Bau der ganzen Anwendung. Ähnliches gilt für:

Mehrsprachigkeit: Nachträglich Übersetzungen in ein System einzuziehen, das nie dafür vorgesehen war, bedeutet oft, jede Textausgabe im Code einzeln anzufassen.
Erweiterbare Berechtigungsstrukturen: Ein starres Admin/Nutzer-Modell lässt sich selten sauber auf feingranulare Rollen umstellen, ohne große Teile der Anwendung neu zu bauen.
Historisierung von Daten: Wenn absehbar ist, dass du später nachvollziehen musst, wer wann was geändert hat, ist das ein Datenmodell-Entscheid von Tag eins - nicht ein Feature, das man "später ergänzt".

Die Frage, die du im Erstgespräch stellen solltest, lautet nicht "können wir das später ändern", sondern "was kostet es, das später zu ändern, wenn wir es jetzt nicht mitdenken". Ein ehrlicher Entwicklungspartner kann diese Frage konkret beantworten.

Dokumentation als Versicherung gegen Personenabhängigkeit

Ein System, das nur die Person versteht, die es gebaut hat, ist eine technische Schuld, auch wenn der Code selbst sauber ist. Wechselt diese Person das Unternehmen, wird krank oder ist schlicht ausgebucht, steht dein Projekt still - unabhängig davon, wie gut die Software eigentlich funktioniert. Verlange deshalb als festen Vertragsbestandteil:

eine Architektur-Übersicht, die auch jemand außerhalb des ursprünglichen Teams in vertretbarer Zeit versteht
Dokumentation der Gründe hinter wichtigen Entscheidungen, nicht nur des Ist-Zustands - warum wurde diese Lösung gewählt, welche Alternativen gab es?
ein Setup, das eine neue Person tatsächlich nachvollziehen und lokal zum Laufen bringen kann, ohne tagelange Rückfragen

Das ist kein Misstrauen gegenüber dem Entwicklungspartner, sondern schlicht Risikomanagement - genau wie eine Versicherung, die du hoffentlich nie brauchst. Mehr dazu, was passiert, wenn ein Entwicklungspartner das Projekt verlässt, findest du im Artikel zur Software-Übergabe und Vendor Lock-in.

"Das räumen wir später auf" ist kein Vertragsbestandteil

Im Projektalltag fällt der Satz "das ist erstmal ein Workaround, das räumen wir später auf" beinahe immer - unter Zeitdruck, bei einer kurzfristigen Anforderungsänderung oder wenn ein Test kurz vor der Abnahme fehlschlägt. Das Problem ist nicht der Workaround selbst, sondern dass dieses "später" in den seltensten Fällen vertraglich irgendwo festgehalten ist. Ohne Budget, Frist und klare Definition dessen, was "aufgeräumt" werden soll, bleibt es bei der Absicht. Wenn ein Team dir eine solche Zusage macht, halte fest:

was genau als Workaround gilt und warum er notwendig war
bis wann die Bereinigung erfolgen soll
ob dafür zusätzliches Budget eingeplant ist oder ob es Teil der ursprünglichen Leistung bleibt

Eine mündliche Zusage, die im Projektabschlussbericht nicht mehr auftaucht, existiert am Ende nicht.

Technische Schulden gehören ins Lastenheft, nicht in die Kulanz

Der wichtigste Hebel liegt aber vor Projektstart: Alles, was oben beschrieben ist, lässt sich als explizite Anforderung in deinem Lastenheft festhalten, statt es als selbstverständlichen professionellen Standard vorauszusetzen. Genau diese Lücke zwischen "das macht man doch so" und "das steht so im Vertrag" ist der Punkt, an dem später Nachforderungen entstehen - der Entwicklungspartner hat formal geliefert, was vereinbart war, nur eben ohne Dokumentation, ohne Erweiterbarkeit, ohne durchdachtes Datenmodell, weil das nirgends explizit gefordert war und im Pflichtenheft entsprechend auch nicht als zu lösende Anforderung auftauchte. Formuliere deshalb konkret in deinem Lastenheft:

welches Maß an Dokumentation als Liefergegenstand gilt
ob und in welchem Umfang das Datenmodell auf absehbares Wachstum (mehr Kunden, mehr Sprachen, mehr Rollen) ausgelegt sein muss
dass die eingesetzten Technologien langfristig unterstützt und nicht nur nach Verfügbarkeit im Team gewählt werden

Ein Festpreis schützt dich vor Kostenexplosion bei der Umsetzung des vereinbarten Funktionsumfangs. Er schützt dich nicht automatisch vor technischen Schulden, die formal innerhalb dieses Funktionsumfangs entstehen, weil niemand sie explizit ausgeschlossen hat.

Fazit

Technische Schulden entstehen nicht durch schlechte Entwickler, sondern durch unausgesprochene Annahmen zwischen Auftraggeber und Entwicklungspartner. Stack-Wahl, Datenmodell, Dokumentation und der Umgang mit Workarounds lassen sich alle schon in deinem Lastenheft adressieren - zu einem Bruchteil der Kosten, die eine spätere Ablösung oder Nachrüstung verursachen würde.

Häufig gestellte Fragen

Was sind technische Schulden in einem Softwareprojekt?

Technische Schulden - im Englischen "technical debt" - sind Abkürzungen oder Entscheidungen, die kurzfristig Zeit oder Kosten sparen, aber langfristig zu teureren Änderungen, größerer Fehleranfälligkeit oder Abhängigkeit von einzelnen Personen führen. Sie entstehen oft unbemerkt, weil sie formal nicht gegen den vereinbarten Funktionsumfang verstoßen.

Wie erkenne ich als Nicht-Techniker, ob der gewählte Technologie-Stack sinnvoll ist?

Frage konkret nach der Größe der Entwickler-Community, ob die Technologie noch aktiv gepflegt wird und ob die Wahl mit den Anforderungen deines Projekts begründet ist oder allein mit der Erfahrung des Entwicklers. Ein seriöser Partner kann diese Fragen klar beantworten.

Warum ist das Datenmodell so schwer nachträglich zu ändern?

Weil spätere Anforderungen wie Mandantentrennung, Mehrsprachigkeit oder Änderungshistorie oft tief in der Datenstruktur verankert sein müssen. Werden sie nicht von Anfang an mitgedacht, bedeutet eine Nachrüstung häufig, große Teile der Anwendung neu zu bauen statt nur zu erweitern.

Wie schütze ich mich vertraglich vor mündlichen Zusagen wie "das räumen wir später auf"?

Halte solche Zusagen schriftlich fest - was genau als Workaround gilt, bis wann er behoben wird und ob dafür zusätzliches Budget eingeplant ist. Ohne schriftliche Fixierung bleibt es bei einer Absicht ohne vertragliche Verbindlichkeit.

Reicht ein Festpreis-Vertrag aus, um technische Schulden zu vermeiden?

Nein. Ein Festpreis schützt vor Kostenexplosion beim vereinbarten Funktionsumfang, aber nicht automatisch vor technischen Schulden, die formal innerhalb dieses Umfangs entstehen. Dokumentation, Erweiterbarkeit und nachhaltige Technologiewahl musst du als Auftraggeber explizit in deinem Lastenheft fordern, damit sie sich im Pflichtenheft des Entwicklungspartners wiederfinden.