Technical Debt

Softwareschulden wurden bereits 1992 von Ward Cunningham mit dem Begriff Technical Debt belegt [Cun92]. Technical Debt steht als Metapher für den zu erbringenden Mehraufwand, der für die Implementierung neuer Features in existierender Software notwendig ist.

Technical Debt

So erfordert die Erweiterung einer schlecht entworfenen und nicht kontinuierlich refaktorisierten Software einen Aufwand von n+x, wobei n für den Aufwand des Features und x für den Aufwand der erforderlichen Aufräumarbeiten und das Beheben von Regressionen steht. Je schlechter der Code, desto größer wird x. Im schlechtesten Fall wird x so groß, dass die insgesamt zur Verfügung stehende Entwicklungszeit ins Aufräumen fließt.

Entstehung Technische Schulden

Technical Debt lässt sich fast nicht vermeiden, aber zumindest minimieren, indem neuer und vorhandener Code kontinuierlich refaktorisiert wird. Kontinuierliches Refactoring setzt das Vorhandensein automatisierter Tests voraus, die sicherstellen, dass der Code nach dem Aufräumen genauso funktioniert wie davor.