<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=772457&amp;fmt=gif">

Die Qualität der Software ist ein zentraler Faktor für den Erfolg des Produktes. Die Folgeschäden von schlechter Qualität können drastisch sein. Technische Schulden sind daher aus unserer Sicht ein absolutes No-Go.

 

Neben dem Geschäftswert bzw. dem Nutzen für den Anwender ist die Qualität der Software bzw. deren Umsetzung 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. 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 und die Folgeschäden von schlechter Softwarequalität für das Unternehmen und seine Kunden drastisch sein können.

In der agilen Softwareentwicklung wird daher 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.

Hinweis: An dieser Stelle möchten wir vorab klarstellen, dass sich technische Schulden niemals zur Gänze vermeiden lassen. Vielmehr geht es um die Einstellung der Entwickler, diese als No-Go zu betrachten.  Nur dadurch kann gewährleistet werden, dass diese auf derart niedrigem Niveau bleiben, dass die Software nachhaltig wartbar bleibt, eine niedrige Cost-of-Change aufweist und so wenig wie möglich Bugs auftreten und wenn doch, dass diese sehr rasch behoben werden können.

Was sind technische Schulden?

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 bzw. Abkürzungen bei der Umsetzung genommen werden. 

Technische Schulden entstehen aber nicht nur durch bewusste Entscheidungen sondern auch durch “versehentlich” beispielsweise aufgrund mangelnder Qualifikation oder Motivation der Entwickler, fehlende Qualitäts- bzw. Coding Standards, etc. Siehe dazu die 4 Typen von technischen Schulden nach Martin Fowler.

Technische Schulden umfassen alle Konsequenzen, die aufgrund mangelhaft umgesetzter Software entstehen sowie Kompromisse, die schon zu Beginn der Entwicklung eingegangen werden. Darunter fällt natürlich auch der Mehraufwand der betrieben werden muss, schlecht programmierte Software zu ändern bzw. deren Funktionen zu ergänzen. Technische Schulden bezeichnen somit bewusste oder versehentliche Fehler, Mängel und Schwächen im Code, die durch mangelnde Kommunikation, Teamleitung, Qualifikation oder übereilte Veröffentlichung von Produkten entstehen und bei ausbleibendem Refactoring konstant anwachsen. 

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.

Qualität kostet Geschwindigkeit - ein Mythos

Dass die Einhaltung von Qualitätsstandards zu einer geringeren Entwicklungsgeschwindigkeit führen, ist ein Mythos und hängt wesentlich vom Betrachtungszeitraum ab. 

Eingangs vielleicht schneller, rächen sich technische Schulden schon nach kurzer Zeit, erfahrungsgemäß bereits nach 6 bis 8 Wochen und führen zum exakten Gegenteil, nämlich zu einer zunehmenden Verlangsamung der Entwicklungsgeschwindigkeit.

Bei einem professionellen Entwicklerteam ist darüber hinaus davon auszugehen, zumindest sollte dies der Anspruch sein, dass sämtliche Praktiken, Standards, Vorgehen, Frameworks, Tools, CI/CD Infrastruktur, etc. bereits vorhanden sind und somit nicht erst für das Projekt aufgebaut werden müssen. Diese stehen also bereits von der “Stunde Null” weg als Startpunkt zur Verfügung und reduzieren damit das Potential von technischen Schulden deutlich. Wenn also Qualitätsstandards von Anfang an quasi als DNA gegeben sind, führt deren Einhaltung nicht zu einer Verlangsamung, sondern zu einer ausgewogenen Symbiose von Qualität und Tempo auf hohem Niveau.

Technisch Schulden - der leise Killer ihrer Software

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. Die innere Qualität des Produkts ist schlecht, es ist möglicherweise fehlerhaft, schlecht getestet oder enthält unsauberen, schlecht wartbaren oder unverständlichen Code. 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, dass 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.

Typische Beispiele für 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.

Wann erscheinen technische Schulden 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 und die Wartung der Software haben. Rechnerisch ist davon auszugehen, dass aufgrund mangelhaft programmierter Software der Aufwand für Änderungen und/oder Erweiterungen um 60% bis 100% steigt.

Toxische Nebenwirkungen technischer Schulden

  • 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, bzw. dem Entwicklerteam nicht frühzeitig die notwendige Zeit eingeräumt wird, die Schulden zu bereinigen. Kein Entwickler mit entsprechenden 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.

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.

Beachten Sie daher folgende Tipps:

  1. Bei der Auswahl eines Software Entwicklungspartner achten Sie darauf, dass dieser nach den einschlägigen Standards und nach Best Practice arbeitet und machen Sie an dieser Stelle keine Kompromisse.
  2. 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.
  3. Lassen Sie periodisch Code Reviews bzw. Audits durch externe Professionisten durchführen. 
  4. Implementieren Sie eine “Zero Bug Policy
  5. 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.
  6. 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”. Wenn du ein Startup bist, gilt das umso mehr. Die finanziellen Mittel sind eingeschränkt, daher muss der “erste Schuss” sitzen.
  7. Messen Sie die Softwarequalität und Security laufend durch entsprechende Tools bzw. Metriken z.B.: via SonarQube.
  8. Im Falle, dass Sie mit einem Dienstleister arbeiten wollen, bestehen Sie auf entsprechende Qualitätsgarantien z.B:. “Frei von bekannten Fehlern”.
  9. Im Zweifel verzichten Sie lieber auf ein weniger wichtiges Feature als Kompromisse bei der Qualität zuzulassen. 

Sie wollen mit einem Team von echten Profis für die Entwicklung Ihrer Software arbeiten, für die technische Schulden ein No-Go sind?

Hier geht's zu unseren Entwicklungsleistungen. 

JETZT HERUNTERLADEN!

 

Für E-Mail-Updates anmelden!

Abonnieren Sie jetzt den Objectbay Blog und erhalten Sie monatlich die besten Beiträge rund um agile Softwareentwicklung.

Für E-Mail-Updates anmelden

Suchen