“Wenn wir das jetzt anfassen, dann sollten wir es diesmal aber richtig machen.” Genau diesen Satz habe ich letztens von einem Team in einem schnell wachsenden Unternehmen gehört, ausgesprochen mit einer gehörigen Portion Frustration. Das Team hatte ambitionierte Ziele, die es auch auf jeden Fall erreichen wollte. Die Diskussion drehte sich um die Frage, wie das Ziel erreicht werden kann. Das Team musste entscheiden, ob sie eine umfangreiche Änderung an der Architektur inkl.

Warum sollte man Code Reviews im Team durchführen? ‘Hä? Was soll denn das?’ ist ein Satz, den man öfters hört, wenn man mit Systemen arbeitet, die schon ein paar Jahre auf dem Buckel haben und an denen viele verschiedene EntwicklerInnen gearbeitet haben. Das Ziel regelmäßiger Code Reviews im Team ist es die ‘Hä?’-Momente langfristig auf ein Minimum zu reduzieren, indem wir ein gemeinsames Verständnis für guten Code aufbauen. Niemand schreibt perfekten Code.

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.