Technische Schuld

Gemäß Techopedia ist die Technische Schuld „ein Programmier-Begriff, der jene zusätzliche Entwicklungsarbeit beschreibt, die dann anfällt, wenn auf kurze Sicht einfacher Code eingebaut wird – statt die langfristig beste Lösung zu wählen“.

Der Haken: Viele Organisationen sehen Technische Schuld als ein rein technisches Problem. Anders gesagt: Etwas, worum sich das IT-Team einfach kümmern soll. Die Realität sieht jedoch ganz anders aus.

Ein Problem, dass alle betrifft

Es stimmt, dass Technische Schuld nach technischen Lösungen verlangt. Aber die Verantwortung dafür muss letztlich gemeinsam geschultert werden – von IT und Business. Technische Schuld ist nicht nur dafür bekannt, dass sie großen Einfluss auf Betrieb und Wartung von Software-Systemen hat. Sie hat auch das Potenzial, Ihr IT-Kerngeschäft lahmzulegen. Fakt ist: Beide Abteilungen – IT und Business – gehen mit Technischer Schuld ganz unterschiedlich um.

• Das IT-Team hat ein perfektes Verständnis von Technischer Schuld – aber scheitert daran, zu erklären, welche Konsequenzen daraus für das Business entstehen.
• Die Business-Abteilung ist sich der Existenz von Technischer Schuld bewusst – aber weigert sich die möglichen Risiken für das eigene Handeln einzusehen.

Aus dieser Fehlkommunikation entwickelt sich oft ein wahrer Teufelskreis, der nur noch mehr Technische Schuld anhäuft – bis zu dem Punkt, an dem das System selbst mit kleinsten Anpassungen Probleme hat. Martin Fowler’s hilfreicher Graph unterteilt die Ursachen Technischer Schuld in vier Bereiche:

Auch wenn hier in „gut“ und „schlecht“ unterschieden wird, können wir festhalten: Jede Art von Technischer Schuld ist grundsätzlich schlecht.

Bewusste Reaktionen werden meist durch Business-Sorgen angetrieben. Ob die Maßnahmen nun umsichtig oder kopflos erfolgen, spielt keine Rolle. Beispiel: Ein Produkt muss so schnell wie möglich veröffentlicht werden. Oder ein Bug muss sofort behoben werden, etc. Selbst in Fällen, wo sich Unternehmen den Konsequenzen einer übereilten Aktion bewusst sind, werden diese kaum offen angesprochen.

Unbewusste, kopflose Reaktionen sind meist ein Zeichen mangelnder Kompetenz des Teams dahinter. Wenn sich ein Team mit dem Prinzip des Layering abmüht, können Sie sich sicher sein, dass es für den Job nicht geeignet ist. Immer dann, wenn eigene Wissenslücken vom Team nicht erkannt werden, sollten bei Ihnen die Alarmglocken läuten.

Unbewusste, vernünftige Reaktionen auf Technische Schuld lassen in der Regel auch technisch-kompetente Teams schließen. Der Unterschied ist, dass sie sich vollauf bewusst sind, dass Fehler gemacht wurden, die sie nun behutsam wieder in Ordnung bringen.

Die Botschaft richtig rüberbringen

Wie geht man also bestmöglich mit Technischer Schuld um? Das Geheimnis liegt in effektiver Kommunikation:

• Erklären Sie die Folgen Technischer Schuld systematisch und leicht zugänglich.
• Machen Sie die Probleme für jeden sichtbar mithilfe geeigneter Tools.

Um die Risiken Technischer Schuld zu erklären, müssen die Konsequenzen auf eine Weise kommuniziert werden, die auch aus Business-Sicht Sinn ergibt. Klar, das ist leichter gesagt als getan. Hand aufs Herz: IT-Abteilungen sind nicht gerade für Ihre empathische Art bekannt.

Der Schlüssel ist es, unbedingt den IT-Jargon zu vermeiden. Stattdessen müssen die negativen Folgen von Schnell-Lösungen klar aufgezeigt werden. Dazu zwei Beispiel-Szenarios:

• „Wenn wir diesen einfachen Weg gehen, wird unser Nutzerdatenmodell vom Active Directory getrennt. Der fehlende Datenaustausch wird langfristig große Probleme verursachen.“
• „Die schnelle Lösung würde bedeuten, dass unsere User nicht mehr Single Sign-On Funktionen nutzen können. Sie könnten sich dann nicht mehr automatisch in unsere App einloggen, falls Sie Windows benutzen.“

Alles offen auf den Tisch legen

Technische Schuld für jeden sichtbar zu machen, ist nicht so kompliziert, wie es scheint. Im Grunde läuft es auf groß angelegte Automationen hinaus, die in der Lage sind, statische Analyse-Tools mit einer Automation Pipeline zu verknüpfen – und so regelmäßige Reportings zu erstellen. Zum Beispiel: Linter und Open-Source Plattformen wie SonarQube sind großartige Werkzeuge für allgemein verständliche Quellcode-Analysen. Sie messen auch schrittweise Entwicklungen, so dass jeder sehen kann, ob sich die Lage verbessert oder verschlechtert.

Tools sind aber nicht alles: Umdie Risiken zu senken, die von Technischer Schuld ausgehen, können Organisationen auch andere Prinzipien des Software-Engineering nutzen – wie zum Beispiel Pair Programming und Peer Reviews. Beides sind gute Wege, um Fachwissen zwischen Teams auszutauschen. Und wie Sie sicher schon ahnen, sind solche technischen Analysen ein wesentlicher Teil von Profinit’s Altsystem Beurteilung.