|
07.08.2026 09:30 Uhr |
„Wie kommt deine Mutter mit der Reha zurecht?“ – „Ganz gut, danke.“ – „Ich habe sie aber gestern beim Einkaufen gesehen.“ – Ups, das ist jetzt peinlich. Ungefähr so peinlich wie die Webanwendung, die zum dritten Mal diese Woche stillsteht. Oder das coole neue Feature, das nach sechs Monaten immer noch nicht implementiert ist.
Dabei fängt es immer so harmlos an. „Wir fahren am Wochenende auf die Hütte von meinem Onkel. Kommst du mit?“ – „Nee, hab keine Lust, und schon gar nicht auf diese modrige Hütte“ ist eine schlechte Antwort. Daher besser: „Klingt toll. Aber meinen Eltern geht es gerade nicht so gut, da will ich nicht ein ganzes Wochenende so weit wegfahren. Vielleicht brauchen sie mich.“ Höflich, unspezifisch, Problem gelöst.
Oder in der Welt des Programmierens: Da ist jetzt noch ein Sonderfall aufgetaucht. Der passt überhaupt nicht ins Konzept, aber wir können ja kaum alles komplett umschreiben. Also hier ein weiterer If-Block, da eine Funktion kopiert und mit ein paar kleinen Änderungen versehen. Schnell, unkompliziert, Problem gelöst.
Meistens endet die Geschichte hier. Aber nicht immer.
„Kommst du am Sonntag zum IT-Kaffee? A propos, geht es deiner Mutter besser?“ Wie praktisch, dieses Mal wird die Ausrede gleich mitgeliefert. „Eigentlich ganz gut. Aber nach so einer Hüft-OP ist man halt eingeschränkt. Ich helfe ihr am Wochenende beim Putzen.“ – „Das kenne ich. Mein Onkel musste drei Wochen in die Reha. Wieso ist deine Mutter zu Hause?“ – „Sie wartet noch auf einen Platz. Nächste Woche sollte es losgehen.“ Kurve gekriegt, Wochenende frei gehalten, alles gut.
Parallel dazu im Programmierprojekt: Zu dem Sonderfall haben sich noch ein paar weitere gesellt. Der harmlose If-Block ist zu einem großen Entscheidungsbaum gewachsen, und die kopierte Funktion wurde dreimal erweitert und zweimal weiterkopiert. Alles läuft irgendwie. Also auf zum nächsten Feature, alles gut.
Manchmal geht das Ganze so weit, dass es peinlich wird. Der Schwindel fliegt auf oder die Software wird instabil. Beim Lügen ist oft das Ende klar, etwa weil man sich verplappert. Bei Software ist das weniger eindeutig.
Dort bauen sich technische Schulden auf. Woran erkennt man diese Schulden und ab wann werden sie zum Problem? Software ist nicht per se schuldenbehaftet, nur weil sie alt ist, und nicht jeder kleine Hack führt direkt in eine Schuldenspirale.
Das Problem ist die Passung zwischen Code und Konzept. Peter Naur hat schon 1985 in seinem Artikel „Programming as theory building“ beschrieben, dass ein Programm nicht in erster Linie Code ist, sondern die Instanziierung eines Konzepts – er nennt es sogar Theorie. Ändert man ein Programm, fügt man nicht nur Codezeilen hinzu, ändert oder löscht sie, sondern verändert das Gesamtkonzept.
Wenn Code wächst, verformt sich das Konzept. Das kann auf eine organische Weise passieren, wie ein Anbau an ein Haus. Es kann auch wie eine Delle in einem Luftballon sein: nicht unbedingt schön, aber auch kein Problem. Wenn aber die An- und Umbauten überhandnehmen, verwässern sie das ursprüngliche Konzept. Das Programm ist nicht mehr die Umsetzung eines Konzepts, sondern besteht nur noch aus aneinandergereihten nichtssagenden Codezeilen. Und damit ist absehbar, dass jede Änderung am Code zum Glücksspiel wird.
Was sollte man also tun, um die Katastrophe gar nicht erst entstehen zu lassen?
Die naheliegende Lösung wäre, nie zu lügen und Code immer nur so zu ändern, dass er zum Programmkonzept passt oder das Konzept weiterentwickelt.
Aber ist das realistisch? Will man dem besten Kumpel wirklich einen Vortrag über individuelle Unterschiede bei der Farbästhetik halten, wenn er stolz sein neues Cabrio in neonpink präsentiert? Ein einfaches „sieht toll aus“ mag nicht ehrlich sein, unkompliziert ist es allemal.
Und wer weiß, vielleicht stellt sich nächste Woche heraus, dass der Sonderfall doch nicht gebraucht wird. Oder es kommen noch ein paar ähnliche dazu. Hacks sind auch ein Mechanismus zum Lernen. Wenn man Modifikationen erst einmal „quick and dirty“ in den Code wirft, kann man beobachten, wie sie sich entwickeln und welche Probleme tatsächlich auftauchen. Eine Neukonzeption des Programms für jede kleine Änderung bedeutet, die Software ins Koma zu legen, um sie vor dem Tod zu bewahren.
Besser ist es, Hacks zuzulassen und sich dessen bewusst zu sein. Das sind die Momente, in denen ausführliche Kommentare im Code (nicht nur in irgendeiner Dokumentation!) angebracht sind: Welche Funktionalität erforderlich war, warum eine schönere Lösung zu umständlich gewesen wäre, welche Stolpersteine dadurch entstehen. Wenn der nächste Sonderfall auftaucht und man auf den Hack noch einen draufsetzt, sieht man zumindest, dass man auf einem wackeligen Fundament aufbaut. Und spätestens, wenn die Kommentare einen halben Bildschirm einnehmen, sollte man sich geschlagen geben.
So wie das Ausräumen der ursprünglich harmlosen Notlüge tut das Aufräumen von Dirty Hacks weh oder kostet zumindest Zeit. Man wollte doch nur den nächsten kleinen Sonderfall einbauen. Wie erklärt man dem Team (und vor allem dem Geldgeber), dass jetzt zwei Monate ohne neue Features anstehen?
Im Grunde ist das der Moment, in dem wir unsere Schulden tilgen müssen. Die kleinen Hacks haben Zeit gespart im Vergleich zum sauberen Umbau des Gesamtkonzepts. Jetzt ist der Zeitpunkt gekommen, das Konzept und den Code wieder in Einklang zu bringen. Das ist auch eine Chance. Offensichtlich haben sich die Anforderungen weiterentwickelt. Wenn man sich diesen Änderungen stellt und das Konzept dafür fit macht, ist man auch für zukünftige Änderungen gerüstet.
Die Frage, wann genau der Zeitpunkt für die Aufräumaktion gekommen ist, ist damit noch nicht geklärt. Ist die Umsetzung neuer Features deshalb so zäh, weil der Code nicht mehr zum Konzept passt oder weil die Features aufwendig sind? Ist der Fehler bei der letzten Änderung technischen Schulden zuzuschreiben oder unvermeidbare IT-Realität? Jede Entwicklerin und jeder Entwickler hat ein gewisses Gespür dafür, wann es einfach keinen Spaß mehr macht, an dem Programm zu arbeiten.
Allerdings haben alle ein unterschiedliches Gespür. Das ist wie bei der Sauberkeit der Küche einer WG. Der eine regt sich schon auf, wenn auf dem Tisch ein paar Brösel liegen, die andere bemerkt das dreckige Geschirr in der Spüle nicht einmal.
Dazu kommt, dass sich nur wenige den Luxus leisten können, die Freude am Programmieren zu optimieren, denn es geht auch um Geld. Leider ist nicht klar, um wie viel. Die Zeit, um ein Ticket abzuarbeiten, kann man messen und in Geld umrechnen. Allerdings kann eine schnell erledigte Aufgabe bedeuten, dass Code und Konzept zusammenpassen und die Änderung deshalb einfach war. Oder die gemessene Zeit enthält undokumentierte Schulden, weil man schnell Code zusammengeklopft hat, der später teuer werden wird.
Erstaunlicherweise scheuen viele Teams die Kosten zum Aufräumen des Codes, die ein paar angekündigte Monate ohne neue Features bedeuten. Dafür nehmen sie die Kosten für überschuldeten Code mit einigen neuen Features und vielen neuen Fehlern hin. Die erste Art von Kosten ist offensichtlich, die zweite ist versteckt. Aber das macht sie nicht günstiger. Wenn eine Bezifferung unmöglich ist, muss man aufs Bauchgefühl vertrauen, idealerweise auf das kollektive.
Das eine Extrem bilden Entwicklerinnen und Entwickler, die schlechten Code erkennen und möglichst frühzeitig vermeiden wollen, quasi die WG-Bewohner, die keine Brösel auf dem Tisch sehen können. Am anderen Ende sitzt das Management, das nicht einsieht, für das dritte kleine Feature zwei Monate gefühlten Stillstand zu akzeptieren, nachdem die letzten beiden kleinen Features in ein paar Stunden erledigt waren. Wer nicht kochen muss, hat kein Problem, wenn die Pfannen schimmelnd in der Spüle liegen.
Es gibt wohl kaum ein IT-Projekt ohne diese Kämpfe. Statt sich gegenseitig zu ärgern, sollten beide Seiten die Sichtweise der jeweils anderen verstehen. Wenn ein erfahrenes Entwicklungsteam unisono schreit, dass der Code auseinanderfällt, wird es einen Grund dafür geben. Wenn eine gesetzliche Anforderung zu einem bestimmten Stichtag umzusetzen ist, kann oder muss auch einmal die Codequalität hinten anstehen. Wichtig ist ein gemeinsames Verständnis und gegenseitiges Vertrauen, dass niemand grundlos Panik verbreitet. Ohne diese Grundlage sollte man sich besser eine andere WG suchen.
Mit jeder kleinen oder größeren Lüge wächst die Erfahrung, welcher Kampf größer wird: die aktuelle Situation auszudiskutieren oder die spätere Peinlichkeit, die mit etwas Glück gar nicht eintritt. Genauso wächst die Erfahrung, welche Dirty Hacks zum Problem werden könnten. Trotzdem wird man immer wieder einmal falsch liegen. Man kann die Zufälle der Zukunft nicht einplanen.
Wichtiger als das grundsätzliche Vermeiden ist die Reaktion, wenn Lügen oder Hacks zum Problem werden. Je länger man es aussitzt, desto schlimmer wird es. So peinlich es ist, wenn jemand seine Lüge weiterspinnt, obwohl er längst aufgeflogen ist, so traurig ist es, wenn Software stirbt, weil der Code kein Konzept mehr hat.
(rme)