Abbildung 1: Code Complexity “Lass uns die einfachste Lösung bauen.” - Aber was genau bedeutet einfach? Allzu oft wird einfach fälschlicherweise mit leicht verwechselt. Doch “einfach” und “leicht” sind zwei grundverschiedene Konzepte. Rich Hickey hat das in seiner Präsentation Simple Made Easy auseinandergenommen. Leicht bedeutet naheliegend. Wenn ein Team die Entscheidung trifft, ein Feature möglichst schnell und einfach umzusetzen, ist damit meist die naheliegendste Lösung gemeint. Die Entwickler kennen sich in einem Stück Code besonders gut aus und beschließen die Änderung dort einzubauen.

Kürzlich wurden wir mit folgendem Problem konfrontiert: Der Großteil der Arbeit eines Teams fließt in Bugfixes und das Beheben von Problemen. Fast nichts anderes geht mehr voran. Lösungen, die in solchen Situationen diskutiert werden, sind meist: Fester Prozentsatz der Zeit des Teams wird zum Fixen der Bugs verwendet No Fix without a test - Für jeden Fix muss ein Test geschrieben werden Bug Bash, ein oder mehrere Sprints in denen nur Bugs behoben werden, um sich wieder Luft zu verschaffen Eine Fastlane für Bugs … Also irgendetwas, das die Symptome lindert und den aktuellen Schmerz behebt.

Hier ist meine persönliche Top 8 der größten Fehler beim Rewrite von Softwaresystemen: Big-Bang Rewrite. Erst muss die gesamte Funktionalität im neuen System abgebildet sein, bevor die Bestandskunden auf das neue System migriert werden. Martin Fowlers Antwort darauf: “If you do a big-bang rewrite, the only thing you’re guaranteed of is a big bang.” Die besten Leute auf das neue System ansetzen, alle anderen bleiben beim Bestandssystem. Sie fühlen sich natürlich wie auf dem Abstellgleis.

Vielleicht kennst du folgenden Dialog oder sogar schon einmal selbst geführt: Product Manager: “Wir müssen das jetzt so schnell wie möglich rausbringen. Wie schätzt du den Aufwand ein?” Engineer: “Schwierig. Die Stelle ist inzwischen echt kompliziert. Da müssen wir erstmal aufräumen, mindestens [deutlich mehr Zeit als erwartet].” Product Manager: “Bekommen wir das nicht einfacher hin?” Engineer: “Das ginge schon irgendwie, aber wir haben schon so viele technische Schulden angehäuft…” Die Diskussion kann beliebig lang weitergehen und in beliebig großen Runden geführt werden.

In diesem Artikel gehen wir auf den Begriffswirrwarr ein und grenzen die Begriffe technische Schulden, Legacy Code und Maintenance Load voneinander ab. Technische Schulden / Tech Debt Dieser Begriff ist sicher dahingehend der problematischste, als dass er oft missverstanden wird und von manchen aus diesem Grund schon bewusst nicht mehr verwendet wird. Ursprünglich geprägt wurde der Begriff von Ward Cunningham, als er an der Entwicklung einer Software im Finanzumfeld beteiligt war.

Jede Technologie ist nur so gut wie das Problem, das sie löst Ein heiß diskutiertes Thema in jeder Softwareentwicklung ist der aktuell verwendete Tech Stack. Sollte nicht doch das neuste JavaScript- oder Microservice-Framework eingesetzt werden? Schließlich wird es zur Zeit auf jeder Konferenz vorgestellt! Sollte nicht jetzt sofort auf eine neue Technologie gewechselt werden, damit wir auch in Zukunft noch anschlussfähig sind? Nicht selten bildet sich hier eine Front zwischen alten Hasen, welche die bestehenden Technologien verteidigen und neuen Kollegen die Probleme gerne anderes angehen würden.

Die Situation gibt es immer wieder: Lange Zeit sind technische Schulden kein Thema, bzw. werden ignoriert. Irgendwann wird die Entwicklung immer langsamer, es treten mehr und mehr Probleme auf. Technische Schulden kommen langsam ins Bewusstsein. Es beginnt die Diskussion, wie man sie in den Griff bekommen kann. Zu dem Zeitpunkt hat sich aber schon soviel angehäuft, dass einzelne Teams überfordert sind. Schließlich müssen neue Anforderungen ja weiter umgesetzt werden. Wenn Umbauten mehrere Teams betreffen und zu groß sind, als dass einzelne Teams sie “nebenbei” bearbeiten könnten, taucht irgendwann ganz automatisch die Idee auf, ein dediziertes Plattform-Team zu gründen.

Warum Code teilen? Teams, die langfristig zusammenarbeiten, werden früher oder später mit mehr als einer Anwendung konfrontiert, selbst wenn sie nicht den ganzen Weg hin zur Microservice-Architektur gehen. Die Vermeidung von Code-Duplikation, ein zentrales Problem in der Softwareentwicklung, wird schnell eine Rolle spielen. Erstmal ist es nicht möglich, von jeder Anwendung auf nützliche Tools und generische Komponenten zuzugreifen, die innerhalb des Teams oder Unternehmens entstanden sind. Dazu ist eine gemeinsame Bibliothek notwendig und der Wunsch nach einer solchen Bibliothek wird sehr schnell lauter.

Diskussionen zwischen Entwicklung und Produktmanagement über technische Schulden sind richtig und wichtig, denn nicht jede technische Schuld muss direkt beglichen werden. Was relevant ist und was nicht, lässt sich tatsächlich am besten im gemeinsamen Gespräch ermitteln. Es fällt aber immer wieder auf, dass sich auch erfahrene Entwickler schwer damit tun, technische Schulden gut zu kommunizieren und auch den Wert von Refactorings klar zu formulieren. Das Produktmanagement sieht hier oft nur die Kosten und nicht den Nutzen, was natürlich zu einer klaren Abwehrhaltung führt.

Ein erfahrenes und eingespieltes Team mit einem hohen Maß an Vertrauen und gegenseitigem Respekt von Entwicklung und Produktmanagement / Product Owner sowie der notwendigen Seniorität und Erfahrung kann dies sicher leisten. Viele - wenn nicht sogar die meisten - Teams sind aber nicht so weit. Es fehlt an Seniorität und Erfahrung. Einzelne Entwickler haben das Gefühl, keine Refactorings durchführen zu dürfen. Alles ist so dringend, dass Refactoring-Themen einfach immer wieder hinten runterfallen.