„Das ist so gewachsen.“
Diesen Satz hört man in der Softwareentwicklung oft.
Er ist normal.
Er ist menschlich.
Software entsteht nicht im luftleeren Raum. Anforderungen ändern sich, Teams wechseln, Prioritäten verschieben sich. Wachstum ist kein Fehler – im Gegenteil: Es zeigt, dass ein System genutzt wird und lebt.
Und trotzdem ist dieser Satz oft ein Warnsignal.
Nicht, weil gewachsener Code per se schlecht ist.
Sondern weil er häufig darauf hinweist, dass sich technische Schulden angesammelt haben – und dass Refactoring längst kein „Nice-to-have“ mehr ist.
Der richtige Zeitpunkt ist selten „später“
Der richtige Zeitpunkt, Code zu überarbeiten, ist meist nicht:
- nächste Woche
- oder „wenn wir einmal Zeit haben“
Denn diese Zeit gibt es im Alltag fast nie.
Aus meiner Erfahrung heraus werden To-Do-Listen für „später“ selten konsequent abgearbeitet. Sie wandern von Sprint zu Sprint, bis sie irgendwann niemand mehr aktiv wahrnimmt.
Warum Refactoring aufgeschoben wird
Die Gründe dafür sind in vielen Teams ähnlich – und nachvollziehbar:
- „Das zahlt uns keiner.“
- „Wir müssen uns auf das Tagesgeschäft konzentrieren.“
- „Wir wollen das Risiko jetzt nicht anfassen.“
- „Niemand kennt den Code mehr gut genug.“
Wenn refactored wird, muss der Code auch zügig deployed werden
Eine weitere Gefahr, die im Entwickler:innen Alltag besteht ist, dass der Code zwar refactored, aber nie oder zu spät deployed wird.
Wenn man es nicht beim nächsten Release macht, ist er schnell veraltet.
Man muss dann entweder mit verheerenden Merge Konflikten rechnen oder ihn ein weiteres Mal refactoren, weil sich schon wieder so viel im System geändert hat.
All diese Gefahren sind keine Ausreden, sondern Symptome.
Sie zeigen Zeitdruck, Wissensinseln und eine starke Fokussierung auf kurzfristige Ziele.
Die eigentlichen Kosten zeigen sich später
Die entscheidende Frage ist nicht, ob Refactoring Zeit kostet –
sondern wer die Kosten am Ende trägt.
Typische Konsequenzen technischer Schulden sind:
- Längere Entwicklungszeiten, weil Änderungen immer komplexer werden
- Höhere Fehleranfälligkeit bei scheinbar kleinen Anpassungen
- Wissen konzentriert sich auf einzelne Personen (Bus-Factor-Risiko)
- Frustrierte Entwickler:innen, die irgendwann das Team verlassen
Das ist kein theoretisches Szenario, sondern gelebter Alltag in vielen gewachsenen Systemen.
Kurzfristiges Denken vs. nachhaltige Entwicklung
Technische Schulden sind nicht grundsätzlich schlecht.
Problematisch werden sie dann, wenn sie nicht bewusst gemanagt werden.
Sauberer, gepflegter Code sorgt langfristig für:
- Nachhaltigen, wartbaren Code
- Kürzere Entwicklungszeiten über den Lebenszyklus hinweg
- Mehr Ruhe und Planbarkeit im Team
- Zufriedenere Entwickler:innen
- Zufriedenere Kund:innen durch weniger Bugs und stabilere Systeme
Refactoring ist damit kein Selbstzweck – sondern eine Investition in Produkt, Team und Organisation.
Autorin
Mag. Rubina Weinzettl