Et dimitte nobis debita nostra. — Matthäus 6, 9 – 13
Der Markt verzeiht keine Fehler. — Leitspruch des Marketings
Software-Entwicklung ist üblicherweise aufwendig und kompliziert: Weder wissen die Kunden, was sie eigentlich wünschen; noch wissen die Entwickler, wie sie ein gegebenes Problem (am besten) lösen sollten. So bewegt man sich zwangsläufig im Zick-Zack, baut immer wieder um und häuft mit der Zeit eine Menge Unsinn an. Zeitdruck und die eigene Faulheit tun ihr Übriges: Der ‘eben schnell’ geschriebene Code bleibt – und bleibt – und bleibt…
Then [..] “Bugs” — as such little faults and difficulties are called — show themselves and months of intense watching, study and labor are requisite before commercial success or failure is certainly reached. — Thomas Edison, 1878
Before there was money, there was debt. — David Graeber, Debt: The First 5000 Years, Melville House, 2011
Anders als bei materiellen Dingen fallen solche Nachlässigkeiten bei Software zunächst kaum auf. Computer sind einfach zu schnell, um sub-optimalen Code gleich sichtbar werden zu lassen, und Software ist zu komplex, um Fehlerzusammenhänge sofort augenscheinlich werden zu lassen. Aber auch Probleme, die man nicht sieht, können Ärger machen. Was nutzt ein Web-Shop, der bei der Abnahme perfekt ausschaut, beim ersten Ansturm der Kunden aber zusammenbricht? Oder sich im Folgejahr nicht um ein dringend benötigtes Feature erweitern lässt?
Technische Schuld(en), engl. technical debt, ist ein plastischer Begriff für unsere Nachlässigkeit, Software sauber, schlank und zielgerichtet zu entwerfen, zu implementieren, zu dokumentieren und zu testen.
Üblicherweise unterscheidet man absichtlich und unabsichtlich eingegangene Schuld: Zwingt mich der Termindruck, alles zu ignorieren, was der Kunde nicht sieht – also beispielsweise Architektur, Codequalität und Dokumentation? Oder verstehe ich bestimmte Architekturkonzepte des Projekts nicht und implementiere daher fehlerhaften und schlecht wartbaren Code?
We can easily forgive a child who is afraid of the dark; the real tragedy of life is when men are afraid of the light. ― Plato
Egal welcher Grund technische Schuld entstehen lässt, technische Schuld aufzudecken und zu protokollieren sollte bei jedem IT-Projekt selbstverständlich sein, denn technische Schuld verringert den wahren Wert eines technischen Systems. Ist sie bekannt, kann man damit planen und umgehen. Technische Schuld muss ja nicht schlecht sein. Ist sie aber unbekannt, könnte sich eine Invasion lästiger Käfer genau dann zeigen, wenn man sie am wenigsten braucht. Und dann steht das System – und steht – und steht…
Als Prophylaxe möchte ich hier in den nächsten Wochen ein paar Geschichten rund um technische Schuld erzählen. Bleiben Sie gespannt. Ich bin es auch… (Anm. der Redaktion: In dieser Reihe sind auch erschienen: Auch ein geschenkter Gaul muss mal zum Zahnarzt und Plädoyer für ein “Robustness Mandate”)
Stehen Sie schon vor einem Scherbenhaufen? Projekt-Krisen überwinden – garantiert! Der Berg scheint unüberwindbar? Sie wollen nicht weiterhin zusehen, wie der Kundennutzen aus dem Fokus gerät, die technischen Schulden wachsen, und wirtschaftlicher Erfolg ein Wunschtraum bleibt? 👉 agile-projektrettung.de rufen!
Wir erkennen Handbremsen im Projekt und etablieren gemeinsam mit Ihnen nachhaltige Methoden für zukünftigen Erfolg. Wenn wir Ihr Problem nicht klar adressieren und Ihnen Lösungswege aufzeigen, haben wir unserem eigenen Anspruch nicht genügt – und Sie erhalten Ihr Geld zurück!