Technische Schuld ist kein Bug

Technische Schulden und Bugs sind ständige Begleiter in der Entwicklung von Produkten. Viele Autoren betrachten sie als identisch und setzen den Abbau von Fehlern mit der Rückzahlung technischer Schulden gleich. Dieses Vorgehen ist jedoch falsch. Es reduziert die Transparenz und erschwert somit die Inspektion und Adaption. Dieser Artikel erläutert die Unterschiede zwischen technischen Schulden und Bugs, weshalb er wichtig ist und wie er sich auf die Transparenz in der Produktentwicklung auswirkt.

Kleine Bugs Überall

Die Bezeichnung eines Fehlers als Bug existiert deutlich länger als es Computer, Programmierer oder Softwareentwickler gibt. Bereits im 19. Jahrhundert wurden so im englischsprachigen Raum Fehler an mechanischen Maschinen bezeichet. Dem Begriff liegt die scherzhafte Vorstellung zugrunde, dass kleine Käfer im inneren der Maschinen für ihre Fehlfunktionen verantwortlich sind.

In der Programmierung und Entwicklung von Computern war der Begriff „Debugging“ für die Analyse von Fehlern auch schon während des zweiten Weltkrieges üblich. Populär wurden „Bugs“ dann durch eine von Grace Hopper überlieferte Anekdote. Am 9. September 1947 gab es am Mark II Aiken Relay Calculator einen Fehler. Dieser war letztendlich auf eine Motte in einem der Relais zurückzuführen. Die Ingenieure klebten den Käfer in das Logbuch des Rechners und bezeichneten ihn als „den ersten Fall in dem ein echter Bug gefunden wurde“. Die entsprechende Seite wird heute von der Smithsonian Institution aufbewahrt.

Diese Beschreibungen aus dem 19. und 20. Jahrhundert geben Aufschluss darüber was ein Bug ist. Ein Bug ist eine Anomalie, welcher zu einer Fehlfunktion oder einem kompletten Funktionsausfall führt. Es handelt sich um eine Verletzung der gegebenen Anforderungen. Der Ist-Zustand des Produktes weicht vom Soll-Zustand ab.

Die ISTQB definiert einen Bug als eine Fehlhandlung (Error) die zu einem Fehlerzustand (Defect) führt, der eine Fehlwirkung (Failure) nach sich ziehen kann. Auch hier ist der eindeutige Bezug zu einer Verletzung von Anforderungen nachvollziehbar. In der Theorie ist es durchaus möglich eine fehlerfreie Software zu entwickeln. Es zeigt sich aber, dass dies praktisch fast unmöglich ist. Daher ist davon auszugehen, dass fast alle Sofwaresysteme Fehler enthalten, auch wenn diese nicht immer Auswirkungen auf das Nutzererlebnis haben.

Mehr Über Technische Schulden

Technische Schulden sind eine Metapher in der Informatik. Sie beschreibt die möglichen Konsequenzen schlechter technischer Entscheidungen und Umsetzungen. Die Schulden sind hierbei die Aufwände die man einplanen muss um diese Umsetzungen durch ein Refactoring zu reduzieren oder ganz auszumerzen.

Es werden verschiedene Arten von technischen Schulden unterschieden. Einerseits können technische Schulden bewusst aufgenommen werden, um beispielsweise einen Meilenstein zu erreichen. Aus diesem Grund sind technische Schulden kein Anti-Pattern, denn diese sind immer die Folge von Faulheit und/oder Unprofessionalität. Andererseits können technische Schulden unbewusst gemacht werden, weil Unwissenheit über Best-Practices herrschte. In einer zweiten Dimension kann zwischen umsichtigen und rücksichtslosen Entscheidungen unterschieden werden. Daraus ergibt sich der Quadrant der technischen Schulden.

Technische Schulden können sich in vielen Formen manifestieren. Fehlende Infrastruktur, unzureichende Dokumentation, Missachtung von Coding-Standards und Verwendung von Anti-Pattern sind nur einige davon. Ursachen für die Entstehung technischer Schulden können fachlicher Druck, unzureichende qualitätssichernde Prozesse, ungenügendes technisches Wissen, ungenügende Kommunikation oder hintenangestellte Refactorings sein. Spannenderweise kann sich technische Schuld aber auch anhäufen wenn keiner dieser Punkte zutrifft. Daher gibt es in der Praxis kein Produkt das frei von technischer Schuld ist.

Technische Schulden haben somit eine direkte Auswirkung auf die Wartbarkeit einer Software, und somit auf den Aufwand für Wartung und Weiterentwicklung der Software. Technische Schuld ist einer der wichtigsten Faktoren, warum in Entwicklungsprojekten Meilensteine nicht oder nicht rechtzeitig erreicht werden. Daher ist es sinnvoll die technische Schuld laufend gering zu halten.

Technische Schulden Sind Kein Bug

Wir haben bereits festgestellt, dass es in der Praxis (fast) unmöglich ist fehlerfreie Software zu entwickeln. Ebenso ist es unmöglich technische Schulden komplett zu vermeiden. Die Frage ist nun also, in welcher Beziehung Bugs und technische Schulden stehen. Ein System kann in der Theorie sowohl frei von technischen Schulden als auch von Fehlern sein. In der Praxis ist es tyischerweise beides nicht. Somit ergeben sich vier Kombinationen aus technischer Schuld und Fehlern.

Schauen wir uns nun einige Beispiele für das Zusammenspiel aus technischer Schuld und Bugs an. Stellen wir uns vor, dass wir uns auf der Baustelle eines Hauses befinden.

Ein Beispiel für einen Fehler ohne technische Schulden ist ein falsch installiertes Fenster. Nehmen wir an, der Fenstergriff befindet sich auf der Außenseite des Hauses. Dies ist ein Fehler, der behoben werden kann, indem das Fenster erneut korrekt installiert wird. Dies ist möglich, ohne Änderungen an der Architektur oder anderen zugrunde liegenden Konzepten des Hauses vorzunehmen.

Entgegengesetzt kann aber auch technische Schuld existieren ohne einen Bug zu erzeugen. Das Dach des Gebäudes soll wind- und wasserdicht sein. Dies könnte durch den Einsatz einer großen Plane erreicht werden. Das Dach wäre wind- und wasserdicht, und somit in Bezug auf die Anforderung ohne Bug. Dennoch ist offensichtlich, dass technische Schulden aufgenommen wurden, denn langfristig wird die Plane ersetzt werden müssen.

Wenn wir beide Fälle kombinieren, dann haben wir ein Gebäude mit technischen Schulden (Plane auf dem Dach) und Bugs (falsch eingebautes Fenster). Schlimmstenfalls ist ein Bug auf technische Schulden zurückzuführen. Wenn das Dachfenster immer wieder heraus fällt, weil es sich nicht an der Plane befestigen lässt, dann ist dies ein Bug aufgrund technischer Schulden. Die Fehlfunktion wird sich nur durch einen vorherigen Abbau der technischen Schulden beheben lassen.

Mehr Transparenz durch Unterscheidung

Der Unterschied zwischen technischen Schulden und Bugs ist essentiell für die Transparenz des entwickelten Produktes. Der größte Aufwand in der Abstellung von Bugs liegt häufig in der Analyse der Fehlerursache. Der Aufwand beim Abbau technischer Schulden jedoch liegt im Refactoring der betroffenen Architektur.

Technische Schulden und Bugs identisch zu betrachten und zu behandeln würde die Transparenz an vielen Stellen reduzieren. Es wäre nicht mehr möglich die Fehlerfreiheit des Produktes zu bewerten. Gleichermaßen könnte keine Aussage über die Höhe der technischen Schulden gemacht werden. Dies würde Inspektion und Adaption bezüglich der Produktqualität und der zu ergreifenden Maßnahmen erschweren. In einem Scrum-Team wären also alle drei Säulen des Frameworks verletzt.

Abschließende Gedanken

Technische Schulden sind keine Bugs. Beide Effekte unterscheiden sich grundlegend in ihren Ursachen und Auswirkungen. Bugs sind funktionale Fehler, welche Anforderungen des Produktes verletzen. Technische Schulden sind technische Fehler im Sinne schlechter Design- und Architekturentscheidungen. In der Praxis finden sich sowohl technische Schulden als auch Bugs in (fast) jeder Software. Beides sollte im Idealfall immer niedrig gehalten und zeitnah beseitigt werden. Um die Transparenz zu erhöhen, und somit Inspektion und Adaption des Produktes zu erleichtern, sollten technische Schulden und Bugs immer getrennt von einander betrachtet werden.