Wie technische Schulden ohne Aufwände abbauen?
Die Basis dafür sind Quality-Gates - Prüfungen der Software die, wenn sie nicht erfolgreich bestanden werden, zwingend zu einer unmittelbaren Beseitigung der gefundenen Mängel führen. Idealerweise werden diese Prüfungen automatisiert und verhindern auch technisch, dass vor Beseitigung der Mängel weitergearbeitet werden kann. Beispielsweise sind Pull-Requests derartige Quality-Gates, wenn 1) sichergestellt wird, dass Code nur mittels Pull-Request in den Hauptbranch gelangen kann und 2) bei diesen Pull-Requests z.B. automatisiert auch die Qualität des Codes geprüft wird. Beides lässt sich durch geeignete Werkzeuge technisch sicherstellen.
Beim Limbotanzen mit Softwarequalität wird aber bei Quality-Gates nicht die Qualität der gesamten Software geprüft, sondern nur die Qualität des neuen bzw. geänderten Codes. Gemäß der Pfadfinderregel „Verlasse den Campingplatz sauberer als du ihn vorgefunden hast.“ Wird also die Qualität im Zuge einer Änderung (z.B. Bugfix oder Einbau einer neuen Fachlichkeit) schlechter, so springt die Quality-Gate an und diese Verschlechterung muss erst ausgebaut werden, bevor die Änderung in den Hauptbranch gelangen kann.
Da der geänderte Code ohnedies getestet und deployed werden muss, fällt dafür kein extra Test- oder Deploymentaufwand an. Der Entwickler muss auch den Code verstanden haben (ansonsten hätte er die Änderung nicht einbauen können) - also fällt dafür auch kein extra Einlernaufwand an. Der einzige Aufwand der anfällt ist der, die technischen Schulden beim ohnedies geänderten Code auch gleich auszubauen. Dieser zumeist sehr geringe Aufwand amortisiert sich meist in Kürze, da verringerte technische Schulden so gut wie immer zu höherer Produktivität führt.
In der Praxis kommt es dabei aber immer wieder zu Befindlichkeiten: Junior-Entwickler sind oft der Meinung, dass sie durch die Qualitätsverbesserungen aufgehalten werden ("eine superkomplexe Methode aufteilen kostet mehr Zeit als dort noch eine einzige Zeile Code hinzuzupfuschen"), Senior-Entwickler stört es, größere Probleme dann ausbauen zu müssen, wenn nur ein kleiner Teil davon angegriffen wurde ("warum bei dem kleinen Bugfix den großen Architekturfehler mit ausbauen - da stimmt dann ja meine Schätzung nicht mehr"). Wichtig ist, dass es hier nicht zu Dienst nach Vorschrift und somit Verschlimmbesserungen kommt. Das lässt sich meiner Erfahrung nach am besten dadurch vermeiden, dass ein erfahrener Entwickler in solchen Situationen einspringt, mithilft die Qualität zu verbessern und zu vermitteln, dass qualitativ hochwertige Arbeit sinnvoller ist als schnelle Lösungen.
Warum nenne ich das Limbotanzen? Die Limbostange entspricht der aktuellen Softwarequalität. Wird sie verschlechtert fällt die Stange so wie die Quality-Gates fehlschlagen. Es gilt also immer unterhalb der Stange durchzukommen. Beim Limbotanzen aber wird die Stange immer wieder niedriger gesetzt. Das passiert bei der Prüfung der Softwarequalität beim neuen bzw. geänderten Code automatisch. Im Laufe der Zeit gibt es immer mehr Code, der einmal neu bzw. geändert war und somit inzwischen den Qualitätsanforderungen genügt. Meiner Erfahrung nach schafft man auf diese Art und Weise bis zu 10.000 Zeilen Code pro Jahr und Softwareentwickler ohne Zusatzaufwand auf die gewünschte Qualität zu bringen.
Fazit: Hat man nur genügend Zeit, so lassen sich technische Schulden ohne merkbare Zusatzaufwände sukzessive abarbeiten und die Software auf den Stand der Technik bringen.