Ob für die Entwicklerinnen oder die Leitung eines Unternehmens: Die technische Schuld ist eine zentrale Herausforderung. Ein veralteter Code, eine schlecht konsolidierte Implementierung kann zu viel Komplexität, hohen Kosten und Problemen führen, denen mit Mehraufwand entgegengewirkt werden muss. Als europaweit anerkannter Cloud-Anbieter sehen auch wir uns dieser Dauerherausforderung gegenüber. In diesem Artikel schildern wir unsere Erfahrungen mit dem Problem anhand eines der wichtigsten Produkte unserer Suite mit Online-Produktivitätstools: der Web-Schnittstelle zur Online-Verwaltung der E-Mail-Dienste.

Die technische Schuld tritt häufig in den Hintergrund, da sie für Unternehmen keinen unmittelbaren Wert erzeugt. Gleichwohl kann sie sich schnell als Stolperstein entpuppen, der jeglichen Fortschritt behindert. Julien Arnoux, VP of Engineering

Die technische Schuld: eine Zeitbombe, die für ein Unternehmen kritisch werden kann 

Neue Funktionen bereitzustellen kommt bei Nutzern*innen gut an. Folglich wird das Tempo häufig beschleunigt, und Sachzwänge infolge von Legacy werden in Kauf genommen. Doch dazu später mehr. Wenn Geschäftsziele wichtiger sind als die Qualität des Codes, kommt Folgendes heraus:

Die Entwickler*innen sind frustriert.

Jede Iteration erhöht die technische Schuld weiter. Trotzdem stützt sich die Weiterentwicklung auf Software-Grundlagen, die vor X Jahren entstanden sind und nicht mehr unbedingt dem heutigen Bedarf entsprechen. Man kann nicht die neuesten Sprachen nutzen, die Rechner für die Vorproduktion sind nicht identisch mit den Rechnern für die Produktion, und veraltete Praktiken führen zu zahlreichen Blockaden und Fehleranfälligkeiten. Folglich bleibt alles beim Alten, damit ja nichts kaputtgeht. Unterdessen steigen die Engeneering-Tasks, während die Teams zunehmend unter Druck geraten, weil die Ingenieure*innen aufgrund ihrer Sisyphusarbeit das Handtuch werfen.  

Führungskräfte reagieren mit Unverständnis

Probleme werden normalerweise mit «Quick-Fixes» gelöst, aber jetzt dauert es zwei Wochen, nur um Schaltflächen in der Schnittstelle zu ändern. Um unrealistische Deadlines umzusetzen, werden Entwickler*innen unter Druck gesetzt, die zu nachsichtig sind, weil sie ständig gegen technische Probleme und Bugs ankämpfen müssen. Die Produktivität sinkt, und die Motivation lässt nach.

Der Geschäftsleitung geht es nie schnell genug

Geld und Rentabilität stehen auf dem Spiel. Warum dauert die Wertschöpfung so lange? Warum ist die Website langsam? Warum den Code überarbeiten, wenn damit keines der von den Kunden geäusserten Probleme gelöst wird? Entscheidungsträger könnten beispielsweise versucht sein, Verzögerungen mit einer Sofortlösung wie der Erhöhung der Serverleistung auszugleichen, obwohl dies die zugrunde liegende technische Schuld nicht beseitigt. Die Folge: Die Qualität des Codes wird langfristig immer schlechter.

Die Zahlen sprechen für sich: In Unternehmen soll die technische Schuld für +10% bis 20% der Kosten aller Projekte verantwortlich sein, während die Problemlösung pro Woche und pro Mitarbeitenden bis zu 13.5 Arbeitsstunden verschlingt – ganz zu schweigen von rund 30% des jährlichen IT-Budgets.

Wer den Spagat nicht bewältigt, rennt geradezu gegen eine Wand. Die Risiken liegen auf der Hand:

  • Tempoverlust
  • Sicherheitsprobleme
  • Motivationsverlust der Teams (Technik und Produkt)
  • Schlechte Softwarequalität

Doch was genau bedeutet eigentlich die technische Schuld?

Die technische Schuld entspricht dem Unterschied zwischen dem aktuellen Code und dem idealen Code. Folglich gilt: Je schlechter die Software, desto höher die Schuld.

Letztere ist unvermeidbar – unabhängig davon, ob sie absichtlich entsteht oder nicht. 

Man kann die Qualität des Codes zugunsten eines Nutzens opfern, etwa wenn die time to market sehr kurz oder die verzögerte Lancierung einer neuen Version finanziell nicht tragbar ist. In diesem Fall wird die technische Schuld bewusst in Kauf genommen. Doch häufig ist das nicht der Fall, weil sie inhärenter Bestandteil unserer Branche ist.

Sie nimmt mit jeder Codezeile zu 

Je mehr die Iterationen fortschreiten, desto stärker steigt die Komplexität der Software und das Chaos.

Hauptproblem ist die essenzielle Komplexität unserer Branche. Für den Mail-Service bedeutet dies, dass er schnell und effizient mit einem Mailserver interagieren und eine API bereitstellen kann, die über eine Webapp und mobile Anwendungen genutzt werden kann.

Hinzu kommt die versehentliche Komplexität mit Problemen, die auf die schlechte Qualität des Codes zurückzuführen sind. Zusätzlichen Einfluss üben auch technische Entscheidungen aus, z.B.:  Bei der Überarbeitung der Vorgängerversion des Mail-Service wurde ein Teil der Codebasis aus der allerersten, mehr als 15 Jahre alten Version übernommen. Diese nutzte ein anderes System für die Speicherung von E-Mails. Folglich wurde ein hohes Mass an unnötiger Komplexität übernommen, obwohl dieses System schon lange nicht mehr genutzt wird.

Last but not least: die natürliche Unordnung (Software-Entropie). Es beginnt mit einer einfachen Softwarebasis, die im Laufe der Lebensdauer einer Anwendung mit mehr und mehr Modulen ausgestattet wird. Die Logik kommt durcheinander und wird schwer nachvollziehbar, vor allem wenn Entwickler*innen das Team verlassen. Dann gibt es Teile im Code, die keine Funktion mehr erfüllen, aber die Komplexität erhöhen:

 

Die Folgen einer steigenden technischen Schuld

Letztlich wird mehr Zeit dafür aufgewendet, Probleme auszumerzen – statt Funktionen zu schaffen und den Wert der Software effektiv zu erhöhen:

Wie also lässt sich die technische Schuld bewältigen?

Hier ist eine Art Spagat zu bewältigen und ein Kompromiss zwischen Qualität und Kosten zu finden, der sozusagen als Grundlage für die Softwareentwicklung fungiert.

Mit Transparenz beginnen

Zunächst gilt es, alle Beteiligten wie Kollegen*innen, Vorgesetzte und Geschäftsleitung zu überzeugen. Nicht so einfach? Wichtig ist, die technische Schuld für die Vorgesetzten und die CEOs durch Erläuterung der folgenden Aspekte verständlich zu machen:

  • deutlich machen, dass kurzfristige Gewinne langfristig der Wettbewerbsfähigkeit zuwiderlaufen;
  • klarstellen, dass technische Probleme in den Verlust von Kunden*innen münden;
  • bewusst machen, dass veralteter Code die Vorhersehbarkeit verringert und Projekte undurchsichtig macht.

«Den eigenen Code zu modernisieren, hat nichts mit Entwickler-Snobismus zu tun.» Für Unternehmen ist dies unumgänglich:

Teams, die ihre technische Schuld verringern, setzen bis zu 50 % mehr Zeit frei, um Wertschöpfung zu erzeugen.

Das Kind aus dem Brunnen holen, bevor es zu spät ist

Die Arbeitsweise eines Teams lässt sich nicht über Nacht verändern. Doch verschlimmernde Faktoren müssen bekannt sein, damit diese maximal begrenzt werden können:

  • untragbare Fristen
  • falsche Definition des Bedarfs
  • schlechte Betriebsorganisation (Teams werden zu Silos)
  • fehlende Fachkenntnisse
  • in technischer Hinsicht: schlechte Praktiken, kein Doc, Overengineering, keine Tests etc. 

Drei Faktoren, die die Schuld ebenfalls verschlimmern können:

  • Keine Patentrezepte. Frameworks, die versprechen, alle Probleme zu lösen, gibt es nicht.
  • Nachahmung vermeiden: «Netflix macht Microservices», «Google nutzt Monorepo». Andere zu kopieren, «weil sie es tun», bringt in einem anderen Kontext nicht die erwarteten Ergebnisse (siehe Cargo-Kult). 
  • Broken-Windows-Theorie: Dahinter steckt die Überlegung, dass ein nicht repariertes zerbrochenes Fenster in einem Gebäude zu unsozialem Verhalten und zum Verfall weiterer Fenster sowie anschliessend der Mauern, des Viertels usw. führt. Im Software-Bereich ist dies wohlbekannt: Ist der allgemeine Zustand des Codes bereits schlecht, sinkt die Hemmschwelle, weiteren mittelmässigen Code hinzuzufügen. Das Ende vom Lied: Unmengen von Spaghetticode.

Einige Grundsätze zur Vermeidung:

  • Die Pfadfinderregel: Ein Platz (Code) sollte immer so sauber verlassen werden, wie er vorgefunden wurde. Die Nächsten werden es danken 😉 
  • K.I.S.S. : Keep it simple stupid (einfach ist kompliziert, aber trotzdem nötig).
  • Y.A.G.N.I. : You ain’t gonna need it (wir Entwickler*innen sind gut darin, Dinge hinzuzufügen, die nur vielleicht benötigt werden) 
  • D.R.Y. : Don’t repeat yourself (statt den eigenen Code zu duplizieren, wird versucht, ihn so weit wie möglich zu faktorisieren).

Crafting-Techniken sind generell eine gute Ressource.

Wie kann die bestehende technische Schuld getilgt werden?

Jetzt geht es ans Eingemachte. Der grösstmögliche Effekt lässt sich so erzielen: 

  1. Risikozonen für die technische Schuld identifizieren.
  2. Nutzen aufzeigen und angehen
  3. Kategorisieren: Sicherheit, Wartbarkeit, Automatisierung, Qualitätssicherung, kontinuierliche Integration usw.
  4. die zu tilgende technische Schuld gemäss ihren Folgen priorisieren
  5. Behandeln

Beispiel:

  • «Ich habe eine Dependenz, die seit sechs Monaten überholt ist. Sie wird nicht mehr gewartet, und möglicherweise gibt es Sicherheitslücken.»
  • Nutzen: «potenzielle Vermeidung von Sicherheitslücken».
  • Anschliessend wird dieser Punkt gemäss den anderen ermittelten Schulden behandelt – je nach Prioritäten und der gewünschten Wirkung. 

Bestehende Schulden regelmässig angehen 

Ist eine Schuld bekannt, lässt sich ihre Tilgung planen und in die Roadmap der jeweiligen Produkte / Dienstleistungen integrieren. Dies geschieht in Zusammenarbeit mit dem Product Owner oder Product Manager.

Die ganze Schuld tilgen? Eine Frage des Masses.

Die technische Schuld gleicht einem Langstreckenlauf. Um jeden Preis einen reinen Code anzustreben, ist müssig. Doch auf Qualität zu setzen, trägt wesentlich zum Entwicklungspotenzial bei. Software ohne technische Schuld ist attraktiv für Entwickler*innen und hält sie bei der Stange. Optimal ist, die Schuld regelmässig zu bilanzieren, um das Steuerrad anzupassen und auf dem richtigen Kurs zu bleiben.

Mehr erfahren

Umfassendes Webinar zur technischen Schuld:

In dieser Präsentation wird aufgezeigt, was unter technischer Schuld zu verstehen ist, woher sie kommt, welche Risiken sie mit sich bringt und wie sie verhindert und getilgt werden kann. Julien Arnoux ist VP of Engineering bei Infomaniak. Er ist seit über 15 Jahren in der Tech-Branche tätig, begann als Entwickler, wurde später Lead Dev und schliesslich VP. Die verschiedenen Aspekte in der Entwicklung von Web-Produkten hat er sowohl in technischer als auch organisatorischer Hinsicht verfolgt.