Folge 10 - Technische Schulden

Bei der Softwareentwicklung gibt es ein magisches Dreieck: Der
Kunde will gleichzeitig Hohe Qualität, niedriges Budget, schnelle
Fertigstellung. Es gibt ein geflügeltes Wort: Hohe Qualität,
niedriges Budget, schnelle Fertigstellung - Das sind die 3
Eigenschaften, die du willst. Suche dir 2 davon aus. Bei
technologischen Schulden entschied man sich für niedriges Budget
und schnelle Fertigstellung unter Aufopferung der Qualität.
Faktoren, die führen zu technischer Schuld führen können, sind: •
Unwissenheit • Faulheit • Zeitdruck • Geldmangel • die bewusste
Entscheidung, unreife Prototypen zu produzieren, um sie zu testen
Technische Schulden drücken sich insbesondere durch schlecht
strukturierte IT-Lösungen aus. Daraus folgen: • Sicherheitslücken •
Nach Updates funktionieren einige Dinge nicht mehr • Neue
Funktionen hinzuzufügen wird sehr teuer/aufwendig Technische
Schulden muss man abbauen – aber nicht immer. Denn der Grund, warum
man Technische Schulden überhaupt macht ist, dass das Projekt
schneller voran geht. Oft weiß man nicht, ob der Kunde ein Feature
später behalten oder wieder wegwerfen will. Auch will man die Zeit
nicht direkt investiren, alles „ordentlich“ zu machen, da man noch
genügend andere Sachen zu tun hat. Technologische Schulden fordern
Zinsen, aber auch Zinseszinsen. Und genau um die Zinseszinsen soll
es gehen: Ist eine Software oder ein IT-Projekt schlecht
strukturiert, kann man den Fehler am Anfang noch einfach beheben.
Je mehr darauf aufbaut, desto schwieriger wird es aber, die Fehler
aus der Vergangenheit zu korrigieren. So entstehen zum Beispiel auf
den Provisorien weitere Übergangslösungen und Hacks, die die
Komplexität des IT-Projekts unheimlich in die Höhe treiben. Zu dem
ursprünglichen Ziel, Zeit zu sparen und schnell nutzbare Ergebnisse
haben, kommen nicht nur die Kosten des “Aufräumens” hinzu, sondern
es werden komplett neue Systeme um das schlecht Strukturierte
System herum gebaut, die im Falle einer Korrektur wieder obsolet
werden – sprich: Verlust durch Abschreibung. Für den Entwickler
können wir folgende Faustregel mitgeben: Bevor man ein System um
eine Funktion erweitert, wird das System geprüft, ob es für diese
neue Funktion geeignet ist oder umstrukturiert werden sollte. Das
ist zwar etwas mehr Arbeit, während der Kunde auf die schnelle
Umsetzung seines Features wartet. Es lohnt sich aber: Der
Implementierungsaufwand für die neue Funktion sinkt drastisch, wenn
das darunterliegende System besser geeignet ist. Veranschaulicht
heißt das: Bevor man neue technologische Schulden aufnimmt, muss
man die alten Kredite abbezahlen Damit man Herr über seine Schulden
bleibt, sollte man diese in einer Art „technischem Schuldenbuch“
dokumentieren. Dazu eignen sich prinzipiell zwei Techniken: In der
ersten Technik schreibst du alles, was du noch nicht implementieren
willst, als Kommentar in den Code: Ausgelassene
Sicherheitsprüfungen mit /* TODO: sanitizen */ - an eine Klasse
konkrete Infos: TODO: Diese Klasse mit Klasse Y zu gemeinsamer
Klasse Z zusammenführen. In der zweiten Technik nutzt du dein
Issue-Tracking-System, um die TODOs zu organisieren. Wenn du ganz
schlau bist, kombinierst du beide Techniken: Im Code machst du
einen Kommentar TODO: #1337: Refactorn und unter der 1337
hinterlegst du dann genaue Beschreibungen, was du dort genau
weggelassen hast. Wenn dich diese Sachen weitergebracht haben, dann
abonniere diesen Podcast.