Wenn Sie ein Softwareprodukt längere Zeit am Markt anbieten und pflegen, fühlt sich die Weiterentwicklung mit der Zeit zunehmend träger und behäbiger an. Als gäbe es eine Art Reibungsverlust, der über die Jahre stärker wird. Um die gewünschten Änderungen zu erzielen, muss zunehmend mehr Energie investiert werden. Dabei beginnt alles so unkompliziert.

Mit der jungen Software ist es ein bisschen wie mit der jungen Liebe – vieles geht einfach wie von selbst. Die Entwicklungsabteilung kann neue Anforderungen zügig umsetzen und die Aufwände sind gut abschätzbar. Die Systemarchitektur hat ein solides Design und verspricht Performance und Flexibilität. Das Entwicklungsteam ist happy mit der eigenen Arbeit und auch der Vertrieb ist zufrieden, da dem Kunden zügig neue, solide Versionsstände und Funktionspakete geliefert werden können.

Doch über die Jahre wird die Weiterentwicklung behäbig. Modifikationen und Neuentwicklungen kleinschrittiger. Die Entwicklungsabteilung reagiert zunehmend kritisch auf Neuanforderungen und Anpassungswünsche. Im System tun sich augenscheinlich neue, unumstößliche Konstanten auf. Dinge, die jetzt nun einmal so seien, und die man nicht ohne weiteres ändern könne.

Das eben beschriebene Muster muss natürlich nicht immer so passieren, aber häufig passiert es eben so. Dafür gibt es verschiedenste Gründe. Ganz allgemein kann man festhalten, dass Softwareprojekte durch eine sehr hohe Dynamik geprägt sind. Das führt im Laufe der Zeit zu ungünstigen Entscheidungen und Fehleinschätzungen, aber auch zu bewussten Kompromissen. Wer kennt nicht Sätze wie "dieser Kuddelmuddel hier ist historisch gewachsen".

Den "Kuddelmuddel" hat man dabei viel weniger unter Kontrolle, als man vielleicht denkt. In Teams die eine Neuentwicklung angehen, findet man oft die Überzeugung, dass der Produktvorgänger nur deshalb ein chaotisches Durcheinander sei, weil das Vorgängerteam geschlampt hätte.

Dementsprechend gibt es dann Ideen und Argumente dafür, warum die Neuentwicklung diesmal nicht zu Chaos führt: Ein bestimmtes Architekturmuster könne die Softwarequalität dauerhaft hochhalten. Es gäbe strikte Guidelines, die verhindern, dass ein System an Qualität verliert. Clean Code-Ansätze könnten die innere Qualität der Software dauerhaft hochhalten. All diese Gedanken sind im Grunde richtig und wichtig - es ist absolut notwendig, dass ein Softwareentwicklungsteam sich derartige Gedanken macht, um positive Voraussetzungen für Softwarequalität zu gestalten.

Trotz aller guter Überlegungen und Vorsätze setzt sich das Chaos aber zu einem gewissen Grad nach einigen Jahren durch. Der Grund ist schlicht und ergreifend der, dass Menschen Fehler machen. Die ausgeklügeltsten Guidelines und Architekturregeln werden vielleicht fünfzig mal eingehalten. Beim einundfünfzigsten mal werden sie gebrochen. Manchmal aufgrund äußerer Umstände, manchmal eben einfach aus Fehlern heraus. Schauen wir uns ein paar typische Gründe an, warum Software über die Zeit an Qualität verliert:

• Personelle Wechsel
  Mitarbeiter und Kollegen kommen und gehen. Jeder personelle Wechsel bringt positive wie negative Veränderungen mit sich. Oft bringt ein neuer Kollege neue Impulse und neues Wissen mit ein, aber auch eigene Vorstellungen, Wissenslücken und einen eigenen Stil. Viele Köche verderben den Brei - das gilt beim Programmieren gleichermaßen. Softwareentwicklung ist ein kreativer Schaffensprozess, der auf sehr unterschiedlichen Detailebenen stattfindet. In einer Übergabe an einen neuen Kollegen lassen sich grobe Zusammenhänge vermitteln, aber keine ganzheitlichen Gestaltungsideen. Der Nachfolger wird eigene Ideen und Konzepte einbringen. An manchen Stellen wird es passen, an anderen Stellen werden Widersprüche entstehen.
  Stellen Sie sich vor, Sie überlegen sich mit Liebe zum Detail ein Konzept für einen Fantasy-Roman, lassen ihn aber von fünf verschiedenen Autoren zeitversetzt schreiben. Wird die Geschichte am Ende aus einem Guss sein und Ihrem ursprünglichen Konzept entsprechen? Vermutlich nicht. So ist es bei der Entwicklung auch - je mehr Wechsel ein Team durchleidet, desto größer sind die dadurch entstehenden negativen Auswirkungen. Frühere Wechsel sind schlimmer als spätere, da die vorgesehenen Strukturen noch nicht gefestigt sind.

Mit der Softwareentwicklung ist es ein bisschen wie bei der Investition in ein Haus: Man muss über die Jahre immer wieder in das Objekt (bzw. Produkt) investieren, um dessen Wert zu erhalten.

Ist Werterhalt die einzige Option? Man kann natürlich alternativ den Verfall der Software akzeptieren und alle paar Jahre das Produkt neuentwickeln. Es liegt aber auf der Hand, dass mit jeder neuen Produktiteration nicht nur sehr viel Geld, sondern auch technisches Wissen und Business-Know-How über Bord geworfen wird. Eine ausgeklügelte Business-Logik in einem großen Unternehmen überträgt man nach einigen Jahren nicht einfach so in ein neues Produkt - man muss sie teils neu erkunden und ergründen. Oft gibt es neben den offensichtlichen Geschäftsprozessen noch viele Feinheiten, Sonderfälle und Ausnahmesituationen, die an verschiedensten Stellen der Bestandssoftware verankert sind. Derartige Details gehen bei der Neuentwicklung oft verloren und müssen durch Fehlersituationen wieder schmerzhaft neu erlernt werden.

Es macht also meistens Sinn, der Vermehrung technischer Schulden entgegenzutreten. Dazu einige Tipps aus der Praxis:

• Nehmen Sie technische Schulden in Ihre KPIs mit auf
  Oft werden technische Schulden als Fachsimpelei der Entwicklung, nicht als wichtige Maßzahl im Projektverlauf wahrgenommen. Dabei spielen sie bei der Bewertung der Qualität des Entwicklungsprozesses, bei der Einschätzung von Risiken und ausstehender Entwicklungskosten sowie bei der Bewertung der Produktqualität eine zentrale Rolle. Die Betrachtung technischer Schulden im Zeitverlauf kann wichtige Rückschlüsse auf Veränderungen im Entwicklungsablauf aufzeigen. So kann ein plötzlicher Anstieg der technischen Schulden auf organisatorische oder fachliche Probleme hinweisen, bzw. kann mit besonders kritischen Abschnitten der Entwicklung in Zusammenhang gebracht werden.
• Legen Sie Wert auf eine strukturierte Erfassung technischer Schulden
  In Ihrem Entwicklungsteam sollte eine Person dafür sorgen, dass technische Schulden an einer zentralen Stelle strukturiert erfasst werden. Dazu gehört die Beschreibung des Problems, dessen Auswirkung sowie die Dokumentation einer möglichen Lösungsidee, welche jedoch nicht in allen Details ausgearbeitet sein muss. Die Dokumentation kann beispielsweise vom Lead Developer bzw. dem Software Architect des Entwicklungsteams wahrgenommen werden. Es ist okay, wenn die Entwicklung zu neuen technischen Schulden führt. Sie sollten jedoch zu jedem Zeitpunkt nach bestem Wissen gesammelt und dokumentiert werden.

  Sinnvolle Informationen sind etwa:

  • Kurbeschreibung der technischen Schuld (Problem und negative Auswirkung)
  • Seit wann besteht das Problem?
  • Wodurch kam das Problem zustande bzw. wieso existiert es? (Beispiel: Ein Sicherheitsmechanismus wurde nicht entwickelt, weil man sonst die Release-Deadline gesprengt hätte. In diesem Fall ist die technische Schuld also ein bewusster Trade-Off)
  • Einstufung der Kritikalität (Blocker, Unschönheit)
  • Lösungsskizze
  • Zeitschätzung, wie lange die Problembehebung benötigt

Behutsames Management technischer Schulden hilft, wenn deren Aufkommen moderat ist. Ist das System bereits ein heilloses Durcheinander, kann die Anzahl der Probleme einer Art wirtschaftlichem Totalschaden gleichkommen: Die Neuentwicklung ist dann günstiger. Dies ist oft bei Systemen der Fall, die über Jahre technische Schulden angehäuft haben. Neben der schlechten Wartbarkeit sprechen aber eventuell auch noch andere Gründe für eine Neuentwicklung. Typische Motivationen sind dabei die folgenden:

• Das Produkt ist nicht mehr zeitgemäß hinsichtlich User Experience (UX) oder der Benutzeroberfläche. Die Neugestaltung und damit verbundene Abtrennung der bisherigen Benutzeroberfläche wäre mit einem sehr hohen technischen Aufwand verbunden.
• Der technologische Fortschritt in der IT macht dem Produkt zu schaffen: Neue Betriebsysteme oder Prozessoren schränken die Funktionalität ein oder machen die Weiterentwicklung teuer.
• Bei der Entwicklung verwendete Technologien sind veraltet bzw. werden nur noch eingeschränkt gepflegt.
• Das Software Design ist überholt. Man nutzt mittlerweile methodische Ansätze, die in einer deutlich besseren Softwarequalität resultieren.

Im ersten Schritt sollte die Neuentwicklung gegenüber Reparaturmaßnahmen stets sorgfältig abgewogen werden. Dazu sollten die wichtigsten technischen Schulden einmal erfasst und abgeschätzt werden.