Im ersten Artikel dieser Reihe haben wir bereits erläutert, was technische Schulden sind und wann man sie machen oder nicht machen sollte. Jetzt soll es darum gehen, wenn man sie macht, wie man es richtig macht.

Technologische Schulden muss man nicht immer vermeiden. An vielen Punkten macht es Sinn, welche aufzunehmen:

• Ein Projekt muss schnell fertig werden, sonst passiert ein weitaus schlimmeres Übel
• Es steht noch nicht fest, ob der Code überhaupt gebraucht wird oder in Benutzung kommt
• Der Code wird noch nicht im Produktiveinsatz benutzt, sondern dient lediglich zum Einholen von Feedback (z.B. ob das Design stimmt)
• Der Code wird erst später produktiv benötigt, muss aber erst mal eine Lücke füllen (z.B. für Tests anderer Module)

Nichtsdestotrotz bleiben technische Schulden technische Schulden.

Wie man in der Grafik sieht, kommen technologische Schulden immer mit Kosten daher: Irgendwann muss der eingesparte Programmieraufwand nachgeholt werden (Rückzahlung), sowie Übergangslösungen wieder entfernt werden (Zinsen).

Folgende Probleme können auftauchen, wenn technische Schulden nicht getilgt werden:

• Sicherheitsprobleme tauchen erst auf, nachdem die Software jahrelang im Betrieb gewesen ist
• Der Kunde entdeckt nicht implementierte Funktionalität
• Die Software ist derart verbaut, dass bereits neue Module auf der Überganslösung aufbauen: Chaos

Damit man Herr über seine Schulden bleibt, helfen folgende Maßnahmen:

• Ausgelassene Sicherheitsprüfungen als Kommentare im Code beschreiben und dokumentieren
• README schreiben und alle Schulden dokumentieren
• Im UML verkürzte Implementierungen als STUBs markieren

Damit ist es möglich, technologische Schulden noch rechtzeitig zu tilgen, bevor sie Schaden anrichten.