Stell dir vor du fährst Auto und merkst, dass deine Bremsen nicht mehr richtig funktionieren. Doch statt diese direkt reparieren zu lassen, entscheidest du dich zunächst dazu, dein Auto zu waschen und ein neues Radio zu installieren und deine Bremsen provisorisch mit alten Teilen instand zu setzen. So baust mit deiner Priorisierung, der Durchführung anderer Aufgaben und der quick & dirty Lösung eine Technische Schuld (Technical Dept) auf.
Technische Schuld im Laufe der Zeit
Früher oder später rächt sich allerdings diese Herangehensweise, da die Technische Schuld nicht wie erwartet linear zunimmt, sondern mit der Zeit exponentiell wächst.
Indem immer mehr dieser quick & dirty Herangehensweisen innerhalb der Entwicklung verwendet werden, wird der Berg an Schulden immer größer. Dies führt letztendlich dazu, dass zur Lösung der Probleme unzählige Tasks abgearbeitet werden müssen.
Geschuldet ist diese Entwicklung grundsätzlich auch der Tatsache, dass aufgrund der Verwendung von agilen Arbeitsmethoden und DevOps der Druck durch Stakeholder wächst, um in immer kürzeren Zeitspannen mehr zu erreichen.
Im Rahmen dieses Artikels wird näher darauf eingegangen, was technische Schuld genau ist und welche Ursachen es für diese Schulden gibt. Wie sich diese auf ein Produkt oder Service auswirkt. Und wie man sie effektiv verwalten kann.
Was sind technische Schulden?
Immer dann, wenn unsaubere Wege gegangen werden, entsteht eine neue Schuld gegenüber allen beteiligten Stakeholdern. Diese Schuld wird meist dann sichtbar, wenn genutzte Systeme oder Software nicht richtig funktionieren oder instabil laufen. Um diese Fehler zu beheben, bedarf es anschließend erheblichen Mehraufwand.
Dies lässt sich zusätzlich noch weiter vereinfachen, indem man diese Schuld als Kluft zwischen einer wohlüberlegten, designten, entwickelten und getesteten Software und einer Software, die einfach mal so zusammengeschustert wurde, ansieht.
Woran erkennt man technische Schulden?
- Fehlende oder keine Dokumentation: Heutzutage soll schnell und agil gearbeitet werden. Da bleibt die Dokumentation oftmals liegen. Dies führt jedoch dazu, dass meist nur wenige wissen, welchen Stand das Projekt bereits hat. Andere oder neue Mitarbeiter bleiben da außen vor und arbeiten stur darauf los.
- Wir kümmern uns später darum: Klar, Projekte müssen abgeschlossen werden. Doch wie sagt man so schön? “Machs’ gleich richtig, sonst machst du’s doppelt”.
- Copy & Paste aus anderen Projekten
- Abkürzungen und Einsparungen: Qualitätskontrolle und Testings werden beispielsweise aufgrund von Deadlines nicht durchgeführt
- Bugfix und kleinere Anpassungen benötigen länger zur Implementierung
Welche Ursachen gibt es für den Aufbau von technischer Schuld?
Fehlende Vision oder Konzept der fertigen Software
Es sollte von Anfang an klar sein, was entwickelt werden soll. Fehlt dies, kommt es sehr oft zu Nacharbeiten am Design, User Interface, der Architektur oder Infrastruktur. Die führt während des gesamten Projektes zu Problemen und Qualität am Code.
Fehlende oder mangelhafte Dokumentation von Requirements
Oft sind Software-Anforderungen nur vage oder wenig beschrieben. Dies führt dazu, dass Teams und Mitarbeiter nicht zu 100 % wissen, was genau erreicht werden soll. Dadurch entsteht zusätzliche Belastung und damit neue technische Schuld.
Fehlende Kommunikation und hohe Erwartungshaltung durch das Management
Bei Projektstart, neuen Teams oder bei der Zusammenarbeit mit externen Dienstleistern kann es vorkommen, dass eine zu hohe Erwartungshaltung an das Projekt-Team vorherrscht und möglichst schnell erste Resultate erzielt werden sollen. Deshalb gilt möglichst frühzeitig den maximalen Workload zu kommunizieren und so auf Qualität statt Quantität zu setzen.
Unzureichende Zusammenarbeit der Mitarbeiter
Heutzutage wird in der Software-Entwicklung meist mit agilen Methoden wie SCRUM gearbeitet. Dadurch geht man davon aus, dass alle beteiligten Mitarbeiter diese Methodik beherrschen und auf Anhieb miteinander zusammenarbeiten können. Dies ist oft nicht der Fall und führt schnell zu Misskommunikation und Frust im Team. Tickets bleiben liegen und / oder werden nur spärlich bearbeitet. Und täglich kommen neue Issues hinzu.
Flaschenhalseffekt – Fehlende Mitarbeiter, Zeit und zu viele Tasks als Hindernis
Problematisch wird es weiterhin, die “Schulden” abzubauen, wenn Mitarbeiter selbst zum Flaschenhals im Unternehmen werden. Oftmals kann es der Fall sein, dass nur wenige Mitarbeiter sich in Systemen auskennen und diese zu pflegen wissen. Sind diese Mitarbeiter dann verhindert, krank oder kündigen im schlimmsten Fall das Arbeitsverhältnis, kennt sich niemand mehr im System aus und es kommt zu einem vollständigen Stillstand. Ein solcher Fall sollte bereits frühzeitig erkannt werden und aktiv dagegen angegangen werden.
Wechsel der verwendeten Technologie oder einer neuen Version
Täglich gibt es Updates, welche Veränderungen im Code und der Herangehensweise verursachen. Dadurch kann es vorkommen, dass existierende Code-Bausteine überflüssig werden, nicht mehr benötigt werden oder Probleme verursachen. Dies muss erst in einer weiteren Iteration behoben werden und führt wiederum zu technischer Schuld.
Fehlender Prozess zur Qualitätskontrolle
Sowohl bei kleinen als auch großen Teams ist Qualität im Code stets zu überprüfen, um herauszufinden, ob am Ende alle Teile perfekt zusammenarbeiten. Fehlende Prozesse zur Qualitätssicherung verursachen letztendlich zusätzliche Arbeit und weitere Tasks zur Problembekämpfung.
Die Ursachen, die dazu führen, dass technische Schuld aufgebaut wird, können vielfältig sein. Die hier aufgelisteten sind ein erster Anhaltspunkt, um direkt und proaktiv zu handeln.
Wie kann mit technischer Schuld umgangen und diese abgebaut werden?
Unabhängig davon, wie technische Schuld zustande kommt, gibt es einige Handlungsempfehlungen, um die Entstehung proaktiv zu vermeiden.
Priorisierung von Tasks
Wurden Versäumnisse ausgemacht, gilt es zunächst, diese zu dokumentieren und anschließend zu priorisieren. Wie diese Versäumnisse priorisiert und angegangen werden, hängt letztendlich von den geschaffenen Rahmenbedingungen (Team, Arbeitsmethode, strategische Entscheidungen oder den verwendeten Tools) ab.
In agilen Teams ist es meist bereits der Fall, dass in täglichen Meetings oder Sprints die Priorität von Tasks festgelegt wird. Wiederkehrende Issues und andere Tickets werden daher meist höher eingestuft und zeitnah bearbeitet. Zusätzlich ergibt sich die Priorisierung von Tasks auch durch den Impact des Problems auf die ganzheitliche Unternehmung (z.B. Impact auf Usability, Umsatz oder Experience) oder wie wichtig eine Lösung für die Performance des Produkts oder der Software ist. Die restlichen Tickets (z.B. Irrelevant für den derzeitigen Sprint) sollten im Backlog an höchster Stelle abgelegt werden und in den nächsten Meetings mit in den Sprint aufgenommen werden.
Entwicklung eines Code-Styleguides
Eine einfache Möglichkeit technische Schulden nicht entstehen zu lassen, ist es bereits vor Projektstart Richtlinien festzulegen. Dadurch soll sichergestellt werden, dass nicht mehrere verschiedene Herangehensweisen verwendet werden.
Diese sollten im Optimalfall definieren, wie Code genau aussehen soll. Das heißt beispielsweise an welche Stelle Kommata, Breaks oder Klammern gesetzt werden müssen. Dies bietet zusätzlich den wesentlichen Vorteil, dass die Struktur und Layout des Codes übersichtlich sind.
Code Refactoring
In der Hitze des Gefechts kann es schon mal vorkommen, dass Code einfach so geschrieben wird, ohne auf dessen Struktur oder Lesbarkeit zu achten. Dies erschwert im weiteren Projektfortschritt den Überblick zu behalten, Bugs zu fixen oder neue Features zu implementieren. Um Herr der Lage zu werden, bietet das Code Refactoring eine Herangehensweise den vorhandenen Code Schritt für Schritt zu optimieren und zu überarbeiten.
Tools zur Visualisierung von technischer Schuld
Mit Hilfe von einigen Tools lassen sich Versäumnisse oder Strukturprobleme im Code bereits von Anfang an vermeiden oder zumindest im Nachhinein überprüfen und optimieren. Eines davon ist SonarQube.
Dieses Tool analysiert deinen Code auf Qualität, Sicherheit und gibt an, an welchen Stellen Code-Segmente zum Beispiel doppelt enthalten sind. Weiterhin gibt es eine zeitliche Einschätzung an, wie lange der Abbau von technischen Schulden innerhalb des Codes dauert.
SonarQube bietet die Möglichkeit zukünftige technische Schulden bereits beim Build Prozess der Software zu erkennen und kann so konfiguriert werden, dass Builds den Status “failed” erhalten, wenn die technische Schuld zu groß ist.
Keine Individual Code Ownership zulassen
Wie oben bereits angesprochen, ist es keine gute Idee, nur eine bzw. wenige Person(en) / Entwickler für wichtige System verantwortlich (und unersetzbar) sind. Wenn es ein Problem mit der Web-Anwendung gibt, ist der Code-Eigentümer die Person, die es beheben muss. Code Ownership ist schlecht für Code-Eigentümer, weil es ihr und das Unternehmens-Wachstum bremst. Außerdem verursacht Code Ownership Probleme für die Organisation und für die Code Owner. Wenn niemand weiß, wie ein System funktioniert, kann niemand effektive Code-Reviews geben. Schlimmer noch, der Code wird vielleicht gar nicht überprüft.
Wenn das Team für den Code verantwortlich ist, kann jeder dabei helfen, Designentscheidungen zu treffen. Jeder kann sich an der Diskussion über das Systemdesign beteiligen, Ideen einbringen und die Verantwortung für diese Entscheidungen mittragen. Weiterhin ist es nicht mehr so schlimm, wenn ein Mitarbeiter nicht mehr am Porjekt beteiligt oder krank ist.
Zusammenfassung
Man muss sich im Klaren sein, dass “technical debt” zunächst keinen offensichtlichen und spürbaren Mehrwert bietet und es gewisse Zeit in Anspruch nimmt diesen abzubauen. Weiterhin werden die meisten Ergebnisse erst mit der Zeit messbar und sichtbar. Jedoch bedeutet dies nicht, auf der faulen Haut liegen zu bleiben und auf das Beste zu hoffen. Man sollte sich am Ende also die Frage stellen, für welche Schulden ist es sinnvoll, diese abzubauen, welche haben den größten Impact auf geschäftliche oder wirtschaftliche Faktoren und bei welchen würde ein Abbau keinerlei Auswirkungen haben.
