Neben dem Nutzen für den Anwender ist die Qualität der Software ein zentraler Faktor für den Erfolg eines digitalen Produktes. In der Praxis wird dem Thema Softwarequalität oftmals nicht die notwendige Bedeutung eingeräumt.
Technical debt oder auf Deutsch technische Schulden werden nicht wahrgenommen, ignoriert und unterschätzt, obwohl die Forderung nach technischer Exzellenz und gutem Design bereits in den Prinzipien des Agilen Arbeitens angelegt sind. Die Folgeschäden von schlechter Softwarequalität für das Unternehmen und seine Kunden drastisch sein können.
|
Langfristig die Qualität Ihres Produktes sicherstellen - für zufriedene NutzerInnen! Objectbay Code Review Checkliste - erfahren Sie mehr darüber was bei der Qualität, Funktionalität und Architektur von Code zu beachten ist.
|
|
Was ist technical debt?
Der Begriff „technische Verschuldung“ wurde von Ward Cunnigham geschaffen, um technische Kompromisse zwischen Qualität und Geschwindigkeit darzustellen. Technische Schuld entsteht also durch Kompromisse bei der Softwarequalität und fußen auf der These, dass gute Qualität Geschwindigkeit kostet und in bestimmten Situationen, beispielsweise um bestimmte Fristen oder Kundenerwartungen einzuhalten, im Zweifel bei der Qualität der Software Kompromisse eingegangen werden.
Technische Schulden bezeichnen somit bewusste oder versehentliche Fehler, Mängel und Schwächen im Code, die durch mangelnde Kommunikation, Teamleistung, Qualifikation oder übereilte Veröffentlichung von Produkten entstehen und bei ausbleibendem Refactoring konstant anwachsen. Darunter fällt natürlich auch der Mehraufwand der betrieben werden muss, schlecht programmierte Software zu ändern.
Technische Schulden entstehen aber nicht nur durch bewusste Entscheidungen, sondern auch durch versehentlich, beispielsweise aufgrund mangelnder Qualifikation oder fehlende Qualitäts- bzw. Coding Standards. Siehe dazu die 4 Typen von technischen Schulden nach Martin Fowler.
Der Begriff Schulden impliziert wie in der Ökonomie, dass diese inklusive Zinsen zurückgezahlt werden müssen, oder in letzter Konsequenz bei einer Überschuldung zu Insolvenz führen, was in der Softwareentwicklung bedeutet, dass die Software stirbt oder Folgeschäden entstehen können, die ein Unternehmen an die Grenzen seiner finanziellen Belastbarkeit bringen.
Technical debt in Scrum und in der agilen Softwareentwicklung
In der agilen Softwareentwicklung wird die Qualität niemals kompromittiert – sie gilt als nicht verhandelbar. Selbst ein einmaliges Abkürzen ist nachhaltig betrachtet keine gute Entscheidung, da es am Ende mehr Zeit und Geld kostet und in der überwiegenden Zahl der Fälle die ursprünglich mögliche Qualität nicht mehr erreicht wird. Technische Schulden sind daher aus unserer Sicht ein absolutes No-Go.
Welche Konsequenzen hat technical debt in der Softwareentwicklung?
Technische Schulden liefern einen „'negativen Wert“ beispielsweise durch Systemausfälle, schlechte Benutzeroberfläche, negative Kundenzufriedenheit, höhere Supportkosten, geringere Umsätze und Margen, etc.
Technische Schulden bzw. schlechter Code wirken sich bereits nach kurzer Zeit negativ auf die Entwicklungsgeschwindigkeit aus.
Die verfügbare Zeit, um an neuen Features zu arbeiten, sinkt zunehmend. Die Auswirkungen der technischen Verschuldung sind nicht linear, sondern exponentiell. Dies bedeutet, dass das Entwicklerteam immer mehr Zeit damit verbringen wird, die Auswirkungen technischer Schulden zu beheben. Die „Time to Market“ eines Teams nimmt daher deutlich ab.
Technische Schulden führen zu Einbußen im Bereich der Transparenz. Mit zunehmender Anhäufung von technischen Schulden steigt die Komplexität und somit Unvorhersehbarkeit und wird es dem Entwicklerteam somit immer schwerer fallen, valide Schätzungen zu erstellen.
Technische Schulden führen zu einer Demotivation des Entwicklerteams bis hin zu Personal Abwanderungen, insbesondere wenn vom Management zeitlicher Druck ausgeübt wird. Kein Entwickler mit entsprechendem Qualitätsanspruch arbeitet auf Dauer unter Rahmenbedingungen, die ein produktives Arbeiten nicht zulassen.
Technische Schulden führen zu einer Erhöhung der Total Cost of Ownership.
Welche Gründe gibt es für technical debt und wie entstehen technische Schulden?
- Mangelnde Qualitätsstandards und Qualitätsmessung
- Hohe Code Komplexität
- Doppelter Code oder Module
- Fehlende Integrationstests
- Mangelhafte Testautomatisierung und Testabdeckung
- Fehlende oder uneinheitliche Coding Standards
- Fehlendes oder mangelhaftes technisches Wissen
- Nicht eingespielte Entwicklerteams
- Fehlende Erfahrung im Entwicklerteam
- Schlechte Kommunikation zwischen Auftraggeber und Softwareentwicklungs-Partner
- Fehlende Zero Bug Policy
- Fehlende oder mangelhafte Dokumentation
- Schlechte Architektur und/oder Design
- Aufgeschobenes Refactoring
- Fehlendes oder mangelhaftes Wissen über agile Softwareentwicklungsmethoden und Frameworks
Die Liste der typischen technischen Schulden zeigt deutlich, dass diese Punkte mit dem Anspruch eines nach Best Practice arbeitenden Softwareentwickler Teams im groben Widerspruch stehen.
Warum technical debt Ihre Software killt
Ist das Entwicklerteam gezwungen, Kompromisse bei der Qualität einzugehen und liefert etwas, das nicht den Qualitätskriterien entspricht, die vereinbart sind, kann es sein, dass dieser Kompromiss zunächst nur eingeschränkt sichtbar ist. Es wurden vielleicht „Quick & Dirty Hacks“ eingebracht oder die Architektur kompromittiert. Das Entwicklerteam hat etwas geliefert, das vielleicht sogar den Anschein erweckt, als es sei in Ordnung, also „außen hui, innen pfui“.
Ein Team, das sich einmal in diese unkomfortable Situation gebracht hat, hat nur einen Weg aus dieser Misere: Seine technischen Schulden zurückzuzahlen und schnellstmöglich abzubauen. Nachdem es aber mehr Aufwand bedeutet, die Qualität nachträglich einzubringen, wird es mehr Zeit in Anspruch nehmen als ursprünglich dafür notwendig gewesen wäre. Die Folgen der konsequenten Fortführung des Schuldenmachens sind daher weitere bzw. höhere Schulden!
Die Entwicklungsgeschwindigkeit eines Teams, das das nächste Release auf Basis des bereits schlechten Codes fortsetzt, wird nicht schneller sein, sondern langsamer. Je mehr an schlechtem Code gearbeitet wird, desto langsamer wird man. Wiederholt sich nun dieselbe Geschichte erneut und wird aufgrund des langsamen Fortschritts erneut Qualität kompromittiert, dann werden die Schulden höher. Diesmal fällt es allen auch leichter, die ohnehin schon schlechte Qualität noch weiter zu verschlechtern.
Genau hier beginnt Software zu sterben. Irgendwann endet die Qualität in einem mehr oder weniger überschaubaren Haufen Mist („a big ball of mud“).
Die Priorisierung neuer Funktionen gegenüber technischen Schulden birgt ein enormes Risiko. Jedes Mal, wenn Sie diese Wahl treffen, entscheiden Sie sich bewusst dafür, Qualitätsprobleme zu ignorieren.
Wann erscheint technical debt dennoch zulässig?
Es gibt nur sehr wenige Situationen, in denen ein bewusster Kompromiss bei der Qualität zulässig erscheint:
Erstellen eines schnellen Prototyps und Erhalten von Feedback
Als Erster auf dem Markt sein, um sich einen Wettbewerbsvorteil zu verschaffen
Reagieren auf ein unerwartetes Ereignis - „echte“ Notfälle
In allen Fällen gilt aber, dass unmittelbar nach dieser Phase Zeit zum Refactoring bzw. dem Abbau von technischen Schulden eingeplant werden muss, um nicht in die Spirale der bereits oben dargestellten Konsequenzen zu laufen.
Bei einer solchen bewussten Entscheidung, die Qualität zu kompromittieren, sind die damit einhergehenden Risiken bzw. Schulden inkl. Zinsen mit den unterstellten Chancen bzw. Assets gegeneinander sorgfältig abzuwägen.
Dabei ist zu beachten, dass technische Schulden direkten Einfluss auf die Weiterentwicklung, die Wartung der Software und deren Entwicklung zu Legacy Systems haben. Rechnerisch ist davon auszugehen, dass aufgrund mangelhaft programmierter Software der Aufwand für Änderungen und/oder Erweiterungen um 60% bis 100% steigt.
Wie vermeiden Sie technical debt?
- Bei der Auswahl eines Softwareentwicklungs-Partner achten Sie darauf, dass dieser nach den einschlägigen Standards und nach Best Practice arbeitet und machen Sie an dieser Stelle keine Kompromisse.
- Achten Sie darauf, dass das Entwicklerteam bereits eingespielt ist und ein technisches „Onboarding“ eines neuen Projektes in eine bestehende CI/CD Platform innerhalb eines Tages möglich ist.
- Lassen Sie periodisch Code Reviews bzw. Audits durch externe Professionisten durchführen.
- Implementieren Sie eine „Zero Bug Policy“.
- Achten Sie bei der Auswahl eines Softwareentwicklungs-Partners darauf, dass dieser auf das Thema Softwareentwicklung fokussiert ist. Die Wahrscheinlichkeit, dass dieser Partner dann auf höchstem Qualitätsstandard arbeitet, ist erfahrungsgemäß bedeutend höher im Vergleich zu Dienstleistern, die Softwareentwicklung zusätzlich zu anderen Angeboten im Portfolio haben.
- Seien Sie skeptisch, wenn Ihnen erzählt wird, Time to Market ist wichtiger als Qualität. In Realität ist das kein Widerspruch, denn Qualität ist die Voraussetzung für einen Markterfolg. Stichwort: „Do it right the first time“.
- Messen Sie die Softwarequalität und Security laufend durch entsprechende Tools bzw. Metriken z.B.: via SonarQube.
- Im Falle, dass Sie mit einem Dienstleister arbeiten wollen, bestehen Sie auf entsprechende Qualitätsgarantien z.B:. „Frei von bekannten Fehlern“.
- Im Zweifel: Verzichten Sie lieber auf ein weniger wichtiges Feature als Kompromisse bei der Qualität zuzulassen.
Fazit
Technische Schulden sind versteckte Kosten, die sich auf die Wertschöpfung, den Empirismus und auch auf die Moral des Teams auswirken. Auf Dauer werden sie zu einer Situation führen, die für das Unternehmen und alle Beteiligten wie Management, Entwickler, Product Owner, Scrum Master oder Kunden zu einer höchst problematischen Situation führen, die in letzter Konsequenz auch zu massiven finanziellen Einbußen führen können und werden. Daher ist das Zulassen von technischen Schulden, bewusst oder unbewusst, niemals eine gute Idee, zumindest mittel- bis langfristig.
|
Sie wollen mit einem Team von echten Profis für die Entwicklung Ihrer Software arbeiten, für die technical debt ein No-Go ist? Hier geht's zu unseren Entwicklungsleistungen.
|
