„Wer ohne technische Schuld ist, der werfe den ersten Stein.“

Der Aufbau technischer Schulden ist kein Zeichen von fehlender Professionalität - sondern eine alltägliche Realität. Dennoch sollten sie bewusst eingegangen und ihr Abbau entsprechend berücksichtigt werden. Häufig entsteht genau dann Reibung, wenn ein Entwicklungsteam einerseits neue Features umsetzen muss, aber gleichzeitig unter bestehenden technischen Altlasten leidet.

Ein dauerhaftes Ignorieren technischer Schulden birgt Risiken für Softwarehersteller, wie mangelnde Skalierbarkeit und erhöhter Modernisierungsdruck. Sie machen überbordende Refactoring- oder Rewrite-Initiativen erforderlich oder führen im schlimmsten Fall in die „technische Insolvenz“.

Warum nicht einfach neu Schreiben?

Im Laufe der Lebenszeit eines Softwaresystems steht ein Entwicklungsteam immer wieder vor der Frage, ob das komplette Neuschreiben (Re-Write) nicht weniger Aufwand bedeuten würde als die Weiterentwicklung des in die Jahre gekommenen Bestandssystems.

Prinzipiell stellt der Re-Write eine sehr hohe Investition dar. Es gilt parallel das bestehende System zu betreiben und am Neusystem zu arbeiten. Ändern sich dazu noch Architektur, Technologieraum und Betriebsumgebung wird der Wechsel für die vorhandenen Entwickler zur Herausforderung. Auch gilt es zu bedenken, dass das Altsystem meist von einem Neusystem mit weniger Features (MVP) abgelöst wird. Das führt zu Unzufriedenheit bei den Kunden. 

Ratsamer erscheint es daher, das bestehende System gut zu pflegen und kontinuierlich zu modernisieren. Was gilt es also zu tun?

Zeit zum Aufräumen

Um einen Berg von technischen Schulden und eine ständig wachsende Komplexität zu vermeiden, ist es wichtig, kontinuierlich dagegen anzuarbeiten. 

Technische Schulden entstehen übrigens nicht nur beim Entwickeln, sondern auch beim Nicht-Entwickeln. Software altert von selbst, weil es neue Technologien, Updates verwendeter Bibliotheken oder auch neue Architektur-Konzepte gibt. Technische Schulden entstehen also auch, obwohl gar nicht an neuen Features gearbeitet wird. 

Entwicklungsteams können durch regelmäßiges Refactoring, das Einplanen von „Aufräumarbeiten“ und konsequente Dokumentation das Thema dauerhaft gut in den Griff bekommen.

Gelingt dies, ist der Weg für eine effiziente langfristige Entwicklung geebnet. Euer Fokus richtet sich wieder auf Mehrwerte für Kunden und wirksamer Arbeit am Produkt.

Gelingt dies nicht, wird Eure Software über die Zeit unbeherrschbar. Das birgt ein geschäftliches Risiko und führt fast immer zu Demotivation in den Teams.

Technische Schulden kennen und beheben

Die folgenden Hinweise sollen Euch helfen, technische Schulden in Euren Softwaresystemen nicht ausufern zu lassen:

• Geht bewusster mit technischen Schulden um und dokumentiert sie. Denkt daran, dass man Schulden wie bei einem Finanzkredit auch wieder abbauen muss.
• Bewertet kontinuierlich das Ausmaß Eurer technischen Schulden. Setzt hierfür beispielsweise (interne oder externe) Assessments und Audits ein, um sowohl Code als auch Architektur auf technische Schulden zu überprüfen.
• Holt Euch das Feedback von Euren Entwicklern und diskutiert über technische Schulden in etablierten Formaten wie Community of Practices (COP’s) oder Retrospektiven. 
• Betreibt einen aktiven Wissensaufbau (z.B. Schulungen zu Architektur-Basics, Architektur-Patterns) und verteilt das Wissen im Team und darüber hinaus. Oft entstehen technische Schulden aufgrund von nicht genügendem Wissen über Architektur, Programmiersprachen oder Frameworks.
• Macht technische Schulden im Code sichtbar. Nutzt zum Beispiel die Visualisierung im Editor (z.B. “schlechten” Code rot markieren). 
• Etabliert Metriken für technische Schulden, wie zum Beispiel für "schlechte" Abhängigkeiten zwischen Modulen, für Codefragmente, die eigentlich "aufgeräumt" werden müssten oder für die Anzahl der als veraltet (deprecated) markierten Klassen die schon immer mal entfernt werden  sollten.
• Softwarequalität lässt sich testen und damit verhindern, dass neue Schulden hinzukommen die man vorher vielleicht ausgebaut hat. Nutzt hier etablierte Tools und Frameworks wie SonarQube oder ArchUnit für das Testen von Architekturregeln.
• Plant Zeit und Ressourcen zur kontinuierlichen Beseitigung der Schulden ein (z. B. „Clean-up Stories“, Chores pro Sprint)

Darüber hinaus können wir Euch nur empfehlen, proaktiv zu kommunizieren, dass Ihr am Abbau technischer Schulden arbeitet. Somit ist allen Beteiligten (inkl. Euer Kunden) klar, wohin Eure Entwicklungszeit aktuell fließt. Ihr betreibt damit Erwartungsmanagement und verdeutlicht gleichzeitig, dass ihr Euch aktiv um die Qualität des Produktes kümmert.

Setzt Ihr die im Artikel aufgeführten Hinweise kontinuierlich um, so seid Ihr auf einem guten Weg. Verhindert die bereits erreichte Komplexität Eures Systems den richtigen Anfangspunkt zu finden, so meldet Euch gern bei uns.

Wir von DevBoost verschaffen Produkt-Entwicklungsteams den Freiraum wieder wirksam am Produkt zu arbeiten (von der Idee zum neuen Feature) statt sich mit technischen Schulden oder Ressourcenproblemen rumzuschlagen. Wir kennen die Herausforderungen, auf die unsere Kunden regelmäßig stoßen und erarbeiten gemeinsam mit Euch geeignete Maßnahmen.

In unserem Erstgespräch diskutieren wir Eure Situation und entscheiden gemeinsam über die nächsten Schritte.