2018-11-08 6 Minuten

Technical Debt und Philosophie

Was Software-Entwicklung mit deinem Leben zu tun hat.

In einer Woche ist die Prüfung, und du sitzt vor deinen Lernunterlagen. Auf der einen Seite alle Bücher, Foliensätze und Unterlagen, auf der anderen die Altfragen aus dem Vorjahr. Die natürlich mit hoher Wahrscheinlichkeit unverändert auch dieses Jahr Anwendung finden werden.

Was tust du?

Nimmst du den einfachen weg, oder den Weg, der dir langfristig (vermutlich) mehr bringen würde?

Ich muss zugeben, auch ich (oder eigentlich: vor Allem ich) habe im Studium immer den leichten Weg gewählt. Warum was lernen, was man sich erreden auch kann? Es gibt natürlich Vorlesungen und Projekte, wo der 80/20 Ansatz der vollkommen richtige, da realistischere Ansatz ist.

Aber wo es wirklich zählt, ist der einfache Weg vielleicht langfristig nicht optimal. Darum geht es in diesem Artikel.

Also: was tust du?

Du weißt, das Thema ist eigentlich hochrelevant für deine Zukunft. Aber Feiern, Freunde oder sogar andere Prüfungen lassen dich dann zugunsten des einfachen Weges entscheiden. Weil es ja auch viel öfter funktioniert, als nicht. Das muss auch mal gesagt werden.

Ich selbst habe das vor Kurzem am eigenen Leib erfahren, als ich beim hacken Lernen plötzlich in die Effizienz-Falle getappt bin: so viele Computer in so kurzer Zeit wie möglich zu erwischen.

Da musste ich mich dann selbst beim Krawadl nehmen, und wieder aus diesem Modus rauskommen. Schließlich lernt man genau dann wirklich was, wenn man sich voll damit beschäftigt.

Nur weil du 10 Kapitel in 2h durcharbeitest, heisst nicht, dass du irgendetwas dabei gelernt hast.

Wird das jetzt ein Philosophie-Blog?

Na sicher nicht. Obwohl es mich hin und wieder schon reizen würde. Aber worauf ich eigentlich hinaus will:

Der einfache Weg wird immer da sein.

Das ist im Studium vielleicht noch eher egal, als dann im Job und in der Wirtschaft. Und hier schlägt sich die Brücke zu dem Begriff, den ich bereits in der Headline erwähnt habe:

Technical Debt, also die technische Schuld.

Was ist technical debt?

Technische Schuld ist das Konzept der monetären Schuld, umgelegt auf technische Projekte.

Eine technical debt geht man dann ein, wenn man in der Software-Entwicklung eine leichte Lösung jetzt implementiert, anstatt der aufwändigeren, aber dafür ingesamt besseren Lösung.

Der Begriff “Quick and Dirty” bezeichnet genau diesen einfachen Weg.

Diese Schuld ist initial vielleicht noch kein Problem – genauso wie der erste Konsumkredit vielleicht noch nicht das Genick bricht.

Aber was haben Schulden so ans ich?

Zinsen.

Und genau so ist es auch bei technischen Projekten: je mehr dieser Schuld man eingeht, desto schlimmer wird es dann, wenn die Zahlungen fällig werden. Oder technisch formuliert:

Wird zu viel technische Schuld eingegangen, wird ein Software-Produkt oder eine Webseite irgendwann einfach instabil, und der Aufwand für jede kleine Änderung steigt unverhältnismäßig.

Wie äußert sich diese technische Schuld im Alltag?

Die Signale sind vielfältig. Hier also ein paar Beispiele – manche aus meinem Alltag, andere habe ich zum Glück noch nicht erleben dürfen:

  • Jedes Update wird zur “Sein oder Nichtsein”-Frage
    Eine WordPress-Seite sollte zum Beispiel nur in den seltensten Fällen nach einem Update zerstört sein. Traust du dich nicht auf den Update-Button zu klicken (oder machst du gar keine Updates), bist du bereits tief in den Schulden
  • Dein Programmierer sagt Sachen wie “Boah, da traue ich mich nicht hineingreifen”
    Ist das Projekt schon so weit “organisch gewachsen” (Achtung, Euphemismus), dass jede kleine Änderung viele, unmöglich vorherzusehende Konsequenzen haben könnte: du bist tief in den Schulden.
  • Das Projekt hat immer wieder Fehler, von denen du keinen Plan hast, wo sie herkommen
    Warum ist die Webseite schon wieder offline!? Bam! Die Chancen stehen gut, dass du in tiefer technical debt steckst.
  • Es wird immer schwieriger, Deadlines einzuhalten
    Auch das ist ein Zeichen technischer Schuld. Die nächste Rate ist nämlich immer dann fällig, wenn ein Projekt erweitert wird, oder es eine neue Version gibt. Genau dann, wenn du nicht das Geld (sprich: Ressourcen) auf der Seite hast, sie abzuzahlen.
  • Deine Plugin-Liste in WordPress hat mehr als 10 Einträge
    Jedes neue Plugin erhöht deine technical debt. Viel mehr Schnittstellen, viel mehr Chancen, dass ein Update oder sonstige Fehler deine Seite unverwendbar machen.

Was hat das jetzt mit mir zu tun?

Es gibt sogar ein Konzept zur technical debt (Technical Debt Quadrant von Martin Fowler), das ich bisher nicht kannte.

Weil das aber technisch ist, hab ich mir erlaubt, es auf eine Situation anzupassen, die wir alle wahrscheinlich kennen:

Was dieses Ding voraussetzt, ist:

Es gibt eigentlich keine realistische Situation, in der keine technical debt entsteht. Außer eben gar nicht zu programmieren bzw. gar nicht zu leben.

Man muss also wissen, wie man damit umgeht.

Schuldenabbau

Was man aber schon machen kann ist: die Gefahr für übermäßige Schulden verringern. In Projekten sieht das so aus: frühzeitig überlegen, wo denn die Reise hingehen könnte.

Und gute Briefings ausarbeiten.

Wird ein (guter) Programmierer früh über mögliche Situationen oder Erweiterungen an einem Projekt informiert, kann er bereits in frühen Phasen die richtigen Entscheidungen treffen… und damit die Gefahr auf übermäßige technical debt reduzieren.

Aber, und das ist die Crux: nicht ganz auf 0 senken.

Technical Debt ist unvermeidbar. Aber wie reagieren?

Ein Startup, das noch nicht einmal weiß, ob das Produkt jemals funktionieren wird, wird noch keine hochprofessionelle Webseite benötigen. Und selbst wenn, in 6 Monaten sind die Anforderungen komplett andere. Und genau da liegt die Gefahr: es wird die bestehende Webseite an komplett andere Gegebenheiten angepasst:

  • Viel mehr User
  • Neue Funktionalität (z.B. einen Onlineshop zu einem inkompatiblen Theme hinzufügen)

Genau in dieser Situation muss dann gut überlegt werden, ob man nicht die gesamte Webseite neu macht – also Schulden abbaut.

In der Software-Entwicklung gibt es diese (durchaus seltenen Phasen) wo man wirklich die Zeit hat, den Code noch einmal genau durchzugehen, und es richtiger zu machen als beim letzten Mal, als man die Deadline im Rücken hatte.

Webseiten sind dann doch noch kleinere Projekte (zumindest in der Liga, in der ich im Moment unterwegs bin) – da stellt sich die Frage der eingegangenen technischen Schuld nicht so oft – oder gar nicht. Dennoch, ich habe schon mehrere Webseiten gesehen, wo diese Schuld sich langsam anhäuft.

Ich hab dir Philosophie versprochen

Umgelegt auf unser Leben ist dieses Prinzip aber auch nicht uninteressant:

  • Jeder Besuch bei McDonalds
  • Jedes “heute nicht Sport machen”
  • Jedes “Ich will aber nicht aus dem Bett”

häuft sich am Schuldenberg an. Und es wird immer schwieriger, wieder zurück zu gehen.

Nicht umsonst setzt die gesamte Self-Development-Branche darauf, Gewohnheiten zu bilden.

Denn:

Jedes Mal, wenn nicht der einfache Weg gegangen wird, baut sich langfristiges, positives Momentum auf. Zinsen funktionieren nämlich auch in die andere Richtung.

Die Stoiker nennen dies voluntary discomfort. So absurd die Vorschläge teilweise sind:

Das Prinzip dahinter ist nicht nur im Software-Development gültig.

Von Hackern, Wordpress, SEO & Co

  • Wo kommt mein Spam her?
  • Wie leicht ist es, eine Wordpress Seite zu hacken?
  • Wie Umzugsfirmen ihre Gaunereien mit SEO umsetzen

...wöchentlich in deiner Inbox! 🚀

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.