Haben Sie die Erfahrung auch schon einmal gemacht?

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. Die Umsetzung neuer Funktionen wird zunehmend von technischen Arbeiten begleitet, die für das Team und die Projektleitung im Umfang schwer greifbar sind, aber stetig mehr Raum einnehmen. Ein Dschungel aus Workarounds. Im Team werden Stimmen laut, welche die Zukunftsfähigkeit der Software in Frage stellen. Insbesondere neue Mitarbeiter fordern immer häufiger eine Neuentwicklung des Bestandssystems. Den Schwenk hin zu modernen Technologien, hin zu moderner Methodik. Weg von dem heillosen Durcheinander.

Derartige Erfahrungen machen fast alle Unternehmen irgendwann einmal, die produktive Softwaresysteme entwickeln und diese über längere Zeit warten. Doch was sind die Hintergründe? Wieso neigt Softwareentwicklung zu zunehmender Unordnung? Und was können Sie dagegen tun, damit es in Ihren Projekten besser läuft?

In diesem Artikel schauen wir uns das einmal genauer an.

Autor

Marco Bürckel
Geschäftsführer

"Dieser Kuddelmuddel hier ist historisch gewachsen"

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 hat. 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.
  • Zeitdruck

    Zeitliche Engpässe lassen sich in kaum einem Softwareprojekt vermeiden. Am Ende des Tages wird das Projekt von der beschränkten Ressource Geld getragen und jede Investition sollte sich irgendwann rentieren. Häufig kommen weitere Faktoren hinzu, die Zeitdruck auf das Projekt ausüben, wie etwa eine Erwartungshaltung seitens Kunde oder ein Wettlauf um Marktanteile. Man kann zwar gegebenenfalls den Scope eines Releases reduzieren, in der Praxis gehen derartige Phasen aber häufig zu Lasten der Qualität. Die Entwicklung muss nun Abkürzungen nehmen, um ihr Ziel zu erreichen. Das ist nicht immer etwas zwangsläufig schlechtes. Das Potenzial für Fehlentscheidungen und qualitätsmindernde Implementierungen ist in einer solchen Phase jedoch sehr hoch. Eventuell entstehen schadhafte Mechanismen und Strukturen in der Software, die sich nur mühevoll wieder ausmerzen lassen. Folgen jedoch Phasen mit Zeitdruck wellenartig aufeinander, besteht für das Aufräumen wiederum keine Zeit.

  • Unzureichende Erfahrung in Entwicklung und Projektmanagement

    In der Softwareentwicklung gibt es in jedem Jahr etliche neue Innovationen. Technologien und Best-Practices ändern sich regelmäßig. Dies führt dazu, dass auch geübte Entwicklungsteams ihre Erfahrung bei einer Neuentwicklung nur bedingt einsetzen können. In jedem Projekt gibt es Neues zu lernen, und Fallstricke zu beachten. Fehlt dem Team am Anfang die Zeit oder die Bereitschaft zur Einarbeitung, wird wahrscheinlich über das gesamte Projekt hinweg unnötige technische Komplexität aufgebaut, welche die Entwicklung nicht nur verlangsamt, sondern Teile der Projektstruktur im schlimmsten Fall nachhaltig zerstört. Nicht weniger gravierend sind prinzipielle Fehler im Projektmanagement: Unklare Kommunikation, starre Planungsmodelle und ungünstige personelle Besetzung von Teams und Arbeitsgruppen können sich nachhaltig negativ auf die Entwicklungsqualität auswirken.

Es gibt natürlich noch viele weitere Gründe, warum Softwarequalität im Verlauf der Entwicklung sinkt. Gedanklich sollten wir uns an dieser Stelle einfach merken, dass ein Entwicklungsprozess über die Zeit nahezu immer derartigen Effekten ausgesetzt ist. Dies führt dazu, dass in der Entwicklung regelmäßig nachkorrigiert und gegengesteuert werden sollte. Diese Korrekturnotwendigkeiten bezeichnet man als technische Schulden. Sie häufen sich faktisch in jedem Projekt während der Weiterentwicklung, ganz egal wie gut das technische Gesamtgewerk auch entworfen sein mag. Um technische Schulden loszuwerden, müssen sie aktiv im Rahmen von Gegenmaßnahmen abgebaut werden. In vielen Projekten geschieht dies jedoch nicht oder nur unzureichend.

Tipps im Umgang mit technischen Schulden

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:

    • Kurzbeschreibung 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

  • Planen Sie regelmäßig Zeit für die Behebung technischer Schulden in die Entwicklung ein
    Wie ich in der Einleitung des Abschnitts schon ein wenig angerissen habe: Man zahlt für technische Schulden auf die ein oder andere Weise sowieso. Entweder man investiert regelmäßig Zeit in Gegenmaßnahmen, oder man investiert die Zeit bei der Weiterentwicklung der zunehmend schwer wartbaren, chaotischen Software. Es macht also Sinn, ein regelmäßiges Zeitbudget für die Ausbesserung einzuplanen. Die Einplanung konkreter Maßnahmen sollte im Dialog mit der Entwicklung stattfinden. Hierzu wurden im Optimalfall Kritikalität und Zeitaufwand der bestehenden Probleme durch das Team bereits abgeschätzt. Planen Sie in jedem Fall konkrete Maßnahmen über einen fixen Zeitraum ein. Lassen Sie sich von Ihrem Lead Developer darlegen, was die sinnvollsten Maßnahmen sind und wie sich diese positiv auf das System auswirken. Der allgemeine Aufruf zum "Aufräum-Sprint" oder zum "Konsolidierungsmonat" sollte hingegen vermieden werden - zum einen führt er leicht zu überhöhten Erwartungshaltungen, andererseits neigen gleichzeitige Aufräumarbeiten in Form von Refactorings leicht zur Kollision, lassen sich also teils schlecht parallelisieren.
  • Zeigen Sie Verständnis aber auch ein gesundes Maß an Skepsis
    So normal technische Schulden auch sind: sie sind immer auch ein Indikator dafür, dass etwas nicht so passiert ist, wie es hätte passieren sollen. Hinter einer technischen Schuld sollte also immer auch eine Begründung stehen, die das Vorgehen zu einem gewissen Grad nachvollziehbar macht. Dabei geht es nicht um Fingerpointing, sondern insbesondere um zwei Dinge:
    • Das Entwicklungsteam sollte in Retrospektive auf die eigenen Fehler zurückblicken und aus ihnen lernen können. Eine differenzierte Diskussion über technische Schulden bildet eine gute Grundlage dafür
    • Ihnen als Produktverantwortlicher sollte die Diskussion eine Chance geben, Vertrauen zum Team aufzubauen bzw. (neu) zu stärken, in dem Sie plausible Hintergründe zum Entwicklungsverlauf erfahren. Eben dieses Vertrauen bröckelt nämlich schnell, wenn zum Sprintende zum wiederholten Male fünf neue technische Schulden präsentiert werden.

Ausblick: Chaos für Fortgeschrittene - was ist, wenn sich schon zu viel angesammelt hat?

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. Entscheiden Sie sich auf dieser Basis für die Neuentwicklung, muss dies nicht unbedingt heißen, dass man neben dem Bestandsprodukt eine komplette weitere Software hochzieht. Die Parallelentwicklung einer Nachfolgesoftware ist mit einigen Risiken verbunden. Schließlich muss das Bestandsprodukt oft noch weiterentwickelt, gepflegt und released werden. Auf derartigen Nachfolgeprojekten lastet von Natur aus von Beginn an ein sehr hoher Druck.

Eine Alternative hierzu kann es sein, ein Produkt nicht in einem Zug zu ersetzen, sondern im ersten Schritt lediglich bestimmte Einzelteile durch punktuelle Neuentwicklungen auszutauschen. Ein solches Einzelteil könnte ein bestimmtes Feature sein, oder ein technischer Teilaspekt (beispielsweise der Datenbankzugriff). Welche Teile sich für die Ersetzung eignen, hängt individuell von der Software ab. Das Mischprodukt aus Neu- und Altentwicklung sollte jedenfalls funktions- und auslieferungsfähig bleiben. Die schrittweise Ersetzung einzelner Teile wird nun so lange wiederholt, bis aus der Bestandssoftware eine komplett neue Software geworden ist.

Auf dieses Thema werden wir in einem gesonderten Artikel noch einmal zu sprechen kommen.

Abschließende Worte

Ich hoffe, ich konnte Ihnen die ein oder andere Idee zum Umgang mit technischen Schulden und schwer wartbarer Software mit auf den Weg geben. Wenn Sie weitere Fragen haben oder Hilfe bei einer konkreten Problemstellung benötigen, können Sie mich jederzeit kontaktieren. Weitere Informationen zu unseren Dienstleistungen im Bereich Produktentwicklung finden Sie hier.

Wenn Sie künftig über neue Artikel rund um das Thema Softwareentwicklung informiert werden wollen, registrieren Sie sich gerne unverbindlich über folgendes Formular: