Seite 3: Fehler nicht zweimal machen

Inhaltsverzeichnis

Es wurde nun deutlich, warum das Team die Implementierung sperrig empfand und nicht so richtig produktiv wurde. Das Team musste verstehen, ob es Abschnitte oder Halte als Kern seines Modells nutzen wollte. In einer Review mit UX Engineer und Product Owner ergab sich, dass an der Stelle tatsächlich nur ein haltebasierter Algorithmus sinnvoll ist. Ein klassischer Lernprozess, bis das Team zu der Erkenntnis kam, einen solchen Algorithmus verwenden zu wollen.

Ein weiterer Blick auf das neue UML-Modell zeigte jedoch, dass im Kern Zugfahrten mit Abschnitten modelliert wurden. Darüber hinaus sollten Halte aus Abschnitten abgeleitet beziehungsweise berechnet werden. Das war das vollständige Gegenteil der Erkenntnisse, die das Team gesammelt hatte und die Experten für sinnvoll hielten. Letztlich wurde gegen diese Form der Neuimplementierung entschieden. Stattdessen entschied man sich für kleinere Refactorings, die Abschnitte vollständig aus dem Code entfernen. Aber das war nicht der Kernpunkt. Vielmehr kamen grundlegende Fragen auf.

Schulden bewältigen

Welches Problem packt dieses Refactoring an? Sind Refactorings nicht das Mittel der Wahl, um technische Schulden abzubauen? Zumindest erscheint das gängige Meinung oder zumindest Praxis in der Softwareindustrie zu sein. Demgegenüber steht jedoch, dass die Codebasis sauber und gut geschrieben war. Sie war gut getestet und folgte gängigen Softwaredesign-Prinzipien. Allerdings war das grundlegende Modell fundamental ungeeignet, da es den Entwicklern anfangs an Fachwissen über diesen Teil der Fachdomäne und des Problemraums fehlte. Als Ergebnis ihrer Designentscheidungen war der Aufwand für das Hinzufügen neuer Features deutlich höher, als sie mit einem anderen Modell hätten sein müssen.

Wie verhält sich das nun zu technischen Schulden? Wie zuvor erwähnt, manifestieren sich Schulden in der Regel als Aufwandstreiber. Das initiale Erstellen und Implementieren des Modells kosteten Zeit und Geld. Gleiches gilt für die durchgeführten Refactorings. Die Neuimplementierung hätte ebenfalls viel Zeit und Geld gekostet. In diesem Sinn gab es hier eine Menge Aufwandstreiber.

Handelt es sich dabei jedoch um technische Schulden? Nirgends in der Problematik tauchen technische Konstrukte wie Microservices, Message Queues, Datenbanken, fehlende Dokumentation, schlechter Programmierstil oder zu geringe Code Coverage auf. Das Problem dreht sich lediglich um ein Modell, das nicht genügend auf den Anwendungsfall zugeschnitten war. Vielleicht handelte es sich hier nur um die Manifestation der (Miss-)Verständnisse von Entwicklern über die Fachdomäne. Abgesehen von der Tatsache, dass man Code immer als technisches Artefakt ansehen kann, waren hier keine technischen Aspekte zu finden.