Jede kleine Änderung an Ihrer Anwendung dauert drei Wochen? Warum das so ist und was man dagegen tun kann

Sie brauchen nur ein neues Feld in einem Formular. Oder eine Spalte mehr in einem Bericht. Das Team sagt: drei Wochen. Sie fragen, warum, und bekommen eine Erklärung, die Sie nicht verstehen, die aber ernst klingt.

Und Sie erinnern sich, dass es am Anfang anders war. Im ersten Jahr kamen neue Funktionen in wenigen Tagen. Das Team ist nicht schlechter geworden. Das System, in dem es arbeitet, schon.

Warum das passiert: technische Schulden

Stellen Sie sich ein Haus vor, an das zehn Jahre lang ohne Plan angebaut wurde. Jedes Mal hat jemand schnell ein Kabel durch eine Wand gezogen, weil das am schnellsten ging. Heute müssen Sie, um eine Steckdose zu versetzen, drei Wände aufbrechen und hoffen, dass Sie im Nebenzimmer nichts durchtrennt haben.

In der Software heißt das technische Schulden, und sie verhalten sich genau wie Schulden: Jedes Mal, wenn etwas schnell erledigt wird, nimmt man einen Kredit auf. Die Zinsen zahlt man bei jeder folgenden Änderung. Nach einigen Jahren sind die Zinsen höher als der Kredit selbst, und die ganze Entwicklung fließt in die Tilgung.

In einer Anwendung sieht das so aus:

• Alles hängt mit allem zusammen. Eine Änderung an einer Stelle bricht etwas an einer anderen, also muss jede Änderung überall von Hand geprüft werden.
• Es gibt keine automatisierten Tests. Jede Änderung bedeutet, die ganze Anwendung von Hand zu testen, und die Angst vor Fehlern bremst alles.
• Dieselbe Logik ist an zehn Stellen kopiert. Eine Änderung muss zehnmal gemacht werden, und eine Stelle wird immer vergessen.
• Die Auslieferung ist manuell und riskant. Deshalb wird selten ausgeliefert, in großen Paketen, und jedes Mal drücken alle die Daumen.
• Nur eine Person kennt einen Teil des Systems. Alles, was diesen Teil betrifft, wartet auf sie.
• Die Technologie ist veraltet. Eine alte .NET-Version und Bibliotheken, die sich nicht aktualisieren lassen, ohne dass alles andere zerfällt.

Woran Sie erkennen, dass es auch Ihr Problem ist

Sie müssen keinen Code lesen. Es reicht, auf Folgendes zu achten:

• Schätzungen für ähnliche Aufgaben werden mit der Zeit größer
• das Team sagt über manche Teile der Anwendung “das fassen wir nicht an”
• nach jeder neuen Version geht etwas kaputt
• neue Entwickler brauchen Monate, bis sie selbstständig arbeiten
• auf die Frage “warum dauert das so lange” lautet die Antwort immer “es ist kompliziert”

Wenn Sie drei oder mehr davon erkennen, liegt das Problem nicht bei den Menschen, sondern im System.

Was nicht hilft

Mehr Leute einstellen. Mehr Menschen in einem verworrenen System bedeuten mehr Menschen, die sich gegenseitig etwas kaputt machen. Fred Brooks hat es schon 1975 aufgeschrieben: Wer einem verspäteten Softwareprojekt mehr Leute gibt, verspätet es noch mehr. Und einen guten Senior-Entwickler zu finden, dauert ohnehin Monate.

Druck auf das Team. Ein Team unter Druck nimmt noch mehr Abkürzungen, und jede Abkürzung ist ein neuer Kredit. Die Schulden wachsen schneller.

Alles von Grund auf neu schreiben. Das klingt nach einer Lösung, bedeutet aber ein oder zwei Jahre ohne neue Funktionen und das Wegwerfen von allem, was das alte System gut macht. Es ist selten die richtige erste Entscheidung, wie wir auch hier geschrieben haben.

Was hilft

Schulden werden nicht auf einmal abbezahlt, sondern in einer klugen Reihenfolge:

1. BestandsaufnahmeWo die Zeit verloren geht
2. EngpässeWas sich am häufigsten ändert
3. SicherheitsnetzTests und automatische Auslieferung
4. NebenbeiJede Änderung hinterlässt besseren Code

1. Bestandsaufnahme. Ein unabhängiger Blick auf den Code und darauf, wie eine Änderung von der Anforderung bis zur Produktion läuft. Wo genau geht die Zeit verloren: beim Schreiben von Code, beim Testen, beim Warten oder beim Reparieren dessen, was unterwegs kaputtgegangen ist?
2. Engpässe. Nicht alles muss repariert werden. Teile, die niemand anfasst, dürfen hässlich bleiben. Zuerst wird aufgeräumt, was sich am häufigsten ändert, denn dort werden jede Woche Zinsen gezahlt.
3. Sicherheitsnetz. Automatisierte Tests rund um die wichtigsten Teile und eine Auslieferung per Knopfdruck. Wenn das Team keine Angst vor Änderungen hat, werden Änderungen von selbst schneller.
4. Nebenbei. Jede neue Funktion hinterlässt den Code, den sie berührt, etwas besser, als sie ihn vorgefunden hat. Die Entwicklung hält nicht an, und die Schulden werden in Raten abbezahlt.

Erste Fortschritte zeigen sich meist innerhalb weniger Wochen, nicht Jahre, und ohne die Entwicklung anzuhalten. Das beste Maß ist einfach: Wie lange dauert eine typische Änderung, von der Anforderung bis zur Produktion, vorher und nachher?

Wie wir arbeiten

ProCoding ist ein .NET-Studio aus Split, Kroatien, und Systeme aufzuräumen, deren Weiterentwicklung über die Jahre langsam geworden ist, gehört zu den Dingen, die wir am häufigsten machen.

Wir beginnen mit einer Prüfung von Code und Prozess, und Sie erhalten eine Liste der Engpässe, sortiert danach, was sie Sie kosten. Danach räumen wir sie gemeinsam mit Ihrem Team oder an seiner Stelle auf, wie es Ihnen besser passt. Der erste Schritt ist ein kostenloses 30-minütiges Gespräch, in dem wir durchgehen, wie bei Ihnen eine typische Änderung abläuft.