Technical Debt Management

Schuldenfallen im Sourcecode

19.02.2013
Von Tobias Wendehost

Risiken abschätzen

Neben der technischen Komplexität spielte die Transferierbarkeit eine Rolle, da einzelne Komponenten des Programms auch in anderen Softwarearchitekturen integriert werden sollen. Ansonsten musste der Dienstleister die Dokumentation des Sourcecodes beachten, um Änderungen leichter nachvollziehbar zu machen. Gleichzeitig waren das Design der Softwarearchitektur und die sogenannte Naming Convention Conformity wichtig.

Einheitliche Kriterien sind aber nur ein Teil von Technical Debt Management. Grundsätzlich muss ein Unternehmen erst einmal abschätzen, welche Risiken mit einem fehlerhaften Programm-Code verbunden sind. Schätzt der Anwender das Risiko hoch genug ein muss er die Kosten für die Beseitigung berechnen. Eine Firma sollte analysieren, ob sich die Wartung der Software lohnt oder eine Neuanschaffung ratsam ist.

Alfred Aue von Capgemini, rät, Anwendungen möglichst unkomplex zu gestalten. So erhöhe man die Effizienz bei der Wartung.
Alfred Aue von Capgemini, rät, Anwendungen möglichst unkomplex zu gestalten. So erhöhe man die Effizienz bei der Wartung.
Foto: Capgemini

"Wir machen eine 360 Grad Analyse und beurteilen mit unseren Architekten die Dringlichkeit einer Anpassung", erläutert Aue das Problem. Allerdings erscheint es ihm wenig sinnvoll, bestimmte Kriterien bei der Analyse des Sourcecodes zu priorisieren. Die Anwendungslandschaft sei sehr heterogen und für unterschiedliche Lebenszyklen ausgelegt. Aues Tipp lautet ähnlich wie Fraenzkes Erfahrung, die Komplexität einer Anwendung auf niedrigem Level zu halten: "Auf diese Weise erhöht man die Effizienz der Wartung und kann sich mehr Funktionalität für sein IT-Budget leisten."

Fachliche Anforderung hat Vorrang

Verfolgen Softwareanbieter und Dienstleister eine ruhige Politik bei der Beseitigung von Technical Debt, dann lässt sich der Aufwand gegenüber dem Management besser verkaufen. In den meisten Fällen müssen nur einzelne Komponenten innerhalb eines technischen Release-Zyklus angepasst werden, um die Fehlerquote zu verringern. "Wenn sie ein gutes technisches Release gemacht haben, dann funktioniert die Anwendung hinterher genauso wie vorher. Sie bekommen aber bessere Performance, Robustheit, gesteigerte Security sowie eine leichtere Wartbarkeit", ist Gunnar Rühl überzeugt.

Dennoch sprechen für Unternehmen heute noch zwei Dinge gegen den Aufwand von Technical Debt Management. Zum einen setzen viele Firmen bei der Software fast ausschließlich auf funktionale Aspekte, da diese einen kurzfristigen Mehrwert bringen. Ein Argument, dass Rühl nicht verstehen kann: "Wenn ich mein Auto alle 20.000 Kilometer zur Inspektion bringen muss, ist das jedem klar. Das ich das auch bei Software tun muss, ist dagegen vielen unklar." Ein vermiedener Ausfall des Systems sei für Unternehmen schließlich mehr wert als eine überhastete Reaktion, wenn es knallt.

Ein zweites Argument hängt mit den Geschäftsabläufen in vielen Unternehmen zusammen. Stimmen die fachlichen Ansprüche, dann stoppt die IT-Abteilung nicht kurzfristig ein Programm, nur weil sich in der Software Fehler eingeschlichen haben. Hier lautet häufig das Argument: Fachliche Anforderungen gehen vor, IT-Bedürfnisse sind nachrangig. Treten technischen Fehler auf, werden diese dann erst im nächsten Release behoben.