Die Broken-Windows-Theorie: Null Toleranz für Softwarequalität
Viele Unternehmen sparen an der Codequalität: zu aufwendig und zu teuer. Diese Argumentation ist nicht nur falsch, sondern langfristig auch gefährlich.
(Bild: Erstellt mit KI (Midjourney) durch iX-Redaktion)
- Golo Roden
Ich nehme an, Sie kennen das Phänomen: Sie arbeiten an einem Softwareprojekt und entdecken einen Fehler. Eigentlich sollten Sie ihn gleich beheben, doch Sie sind derzeit mit einem Feature beschäftigt, das ohnehin schon verspätet ist. Um den Fehler zu beheben, müssten Sie zudem eine Abhängigkeit aktualisieren, was allerdings nicht ohne Weiteres möglich ist, weil Sie dann in einigen Bereichen des Codes Anpassungen vornehmen müssten.
Da Sie ohnehin schon spät dran sind, treffen Sie die einzig denkbare Entscheidung: Sie verschieben den Bugfix auf "später". Der springende Punkt dabei ist jedoch: Dieses "später" tritt nie ein. Das bedeutet, nach einiger Zeit stehen Sie vor einem großen Berg technischer Schulden und fragen sich: Wie konnte es überhaupt jemals so weit kommen?
Die Broken-Windows-Theorie
Diese Situation ist keineswegs neu. Sie trägt sogar einen Namen: die "Broken-Windows-Theorie". Damit ist nicht gemeint, dass das Betriebssystem Windows erneut defekt ist, sondern der Begriff stammt aus der Stadtplanung. Die zugehörige Idee ist simpel und zugleich wirksam: Es geht darum, warum in bestimmten Stadtteilen Kriminalität offenbar ungebremst um sich greifen kann. Die These der Broken-Windows-Theorie besagt, dass dies geschieht, wenn Stadtteile vernachlässigt werden. Wenn zum Beispiel Gebäude dauerhaft leer stehen und nicht – wie möglicherweise lange geplant – abgerissen werden.
Empfohlener redaktioneller Inhalt
Mit Ihrer Zustimmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.
Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.
Als Symbol dafür wählten die US-amerikanischen Sozialforscher James Wilson und George Kelling in den frühen 1980er-Jahren das zerbrochene Fenster: Wenn eine Fensterscheibe zerbricht und niemand sie ersetzt, zeigt das, dass sich niemand darum kümmert. Da jedoch niemand neben einem leer stehenden Haus mit einer dauerhaft zerbrochenen Scheibe leben möchte, ziehen bald darauf die ersten Nachbarn fort.
Daraus folgen weitere leer stehende Häuser, und jemand wirft dort vermutlich früher oder später ebenfalls eine Fensterscheibe ein. So entsteht langsam eine Kettenreaktion, in der das Viertel weiter verfällt, der soziale Zusammenhalt nachlässt und es irgendwann sehr schwierig werden kann, noch etwas zu ändern, selbst wenn es jemand möchte. Dadurch sinkt die Hemmschwelle gegenüber Kriminalität, was letztlich den gesamten Prozess nur weiter beschleunigt.
New York in den 1990er-Jahren
Die entscheidende Frage lautet nun, wie sich eine solche Entwicklung wieder unter Kontrolle bringen lässt. Tatsächlich gibt es darauf eine Antwort, die in der Vergangenheit bereits funktioniert hat, etwa in New York in den 1990er-Jahren. Dort beschrieb die eingangs geschilderte Lage ziemlich genau den Status quo, und der damalige Bürgermeister (von 1994 bis 2001 war dies Rudolph Giuliani, den Sie vielleicht als ehemaligen Rechtsberater von Donald Trump kennen) verfolgte eine sogenannte "Zero-Crime-Tolerance"-Strategie.
Dabei geht es, wie der Name erahnen lässt, darum, bei jeglichen Verstößen – auch bei kleineren Vergehen wie Falschparken – keinerlei Nachsicht walten zu lassen. Das hatte insofern Erfolg, als die Kriminalitätsrate in den folgenden Jahren stark sank. Allerdings sollte man nicht unterschlagen, dass diese konsequente Polizeipräsenz wiederum kritisiert wurde, da sie manchem zu weit ging. Gerade aus den USA hört man immer wieder von Polizeigewalt und rassistischem Vorgehen, was man natürlich genauso wenig möchte. Zusammengefasst ist es also schwierig, die richtige Balance zu finden, doch eine Null-Toleranz-Strategie trägt natürlich wesentlich dazu bei, wuchernde Kriminalität einzudämmen.
Der Bezug zur Softwareentwicklung
Was hat das nun mit Softwareentwicklung zu tun? Nun, die Broken-Windows-Theorie lässt sich hervorragend auf Softwareprojekte übertragen. Zusammengefasst: Jeder nicht behobene Fehler ist ein zerbrochenes Fenster. Jede Codezeile, die gepflegt werden müsste, aber nicht wird, ist ein zerbrochenes Fenster. Jede veraltete Abhängigkeit, die nicht aktualisiert wird, ist ein zerbrochenes Fenster. Und so weiter. Anders ausgedrückt: Wenn Sie sich nicht konsequent mit einer Null-Toleranz-Strategie um die eigene Codebasis kümmern, führt dies zwangsläufig zu einer Abwärtsspirale in Ihrem Projekt.
Warum ist das so? Weil sich Fehler und technische Schulden addieren. Das bedeutet, dass der Aufwand, sie irgendwann zu beheben, stetig größer wird. Gleichzeitig steigt auch das Risiko, dabei etwas kaputtzumachen. Beides zusammen sorgt dafür, dass niemand sich mehr an den Code wagt, was wiederum nur zu weiteren Fehlern und noch mehr technischen Schulden führt. Man errichtet so ein Fundament, das von Beginn an instabil ist, baut darauf immer weiter auf und macht dieses Gebilde dadurch noch fragiler, bis es zu einem Kartenhaus verkommt, das unweigerlich in sich zusammenfallen muss.
Zusätzlich besteht dann die Angst, bestehende Module anzupassen oder zu erweitern, weil man nicht weiß, ob eine Funktion möglicherweise eine tragende Karte dieses fragilen Konstrukts ist. Folglich umschiffen alle den vorhandenen Code, was die Entwicklung kompliziert, langsam und teuer macht. Und aufgrund dieser Instabilität will sich auch niemand mehr an externe Abhängigkeiten heranwagen, weil dies Aufwand bedeutet. Also bleibt man lieber bei jenen Versionen, die augenscheinlich funktionieren, was jedoch auf lange Sicht die Aktualisierungsmöglichkeiten verbaut und rasch zu Sicherheitslücken oder nicht behobenen Problemen führt.
Offensichtlich ist es riskant, sich nicht um die Codequalität eines Projekts zu kümmern. Doch es kommt noch ein weiterer Faktor hinzu: Denn wer sind die ersten Nachbarn, die eine Gegend mit zerbrochenen Fenstern verlassen? Das sind stets jene, die sich das problemlos leisten können. In Softwareprojekten sind es folglich häufig die besonders fähigen Entwicklerinnen und Entwickler, die als Erste gehen – und das sind leider genau die Personen, die Sie am dringendsten bräuchten, um die Situation noch zu retten, da sie über umfassendes Fachwissen und Erfahrung verfügen.
Die Augen verschließen?
Das klingt überaus dramatisch. Aber so stellt sich die Realität dar. Selbstverständlich können Sie die Augen davor verschließen und sich einreden, bei Ihrem eigenen Projekt sei alles vollkommen anders. Vermutlich finden Sie auch zahlreiche Argumente, weshalb die Entwicklung bei Ihnen gar nicht anders laufen könne. Doch genau damit reden Sie sich die Lage schön. Die Augen zu schließen und zu glauben, andere könnten Sie dann nicht mehr sehen, das ist ein Verhalten, das vielleicht im Kindergarten Sinn ergibt, aber in der Softwareentwicklung schlicht nicht funktioniert. Erschreckend finde ich, wie viele Unternehmen genau diesen Ansatz trotzdem immer und immer wieder wählen.
Möglicherweise fragen Sie sich jetzt, woran Sie konkret erkennen, dass in Ihrem Softwareprojekt bereits einige Scheiben zerbrochen sind. Daher möchte ich Ihnen ein paar typische Anzeichen nennen. Diese Liste hat keine festgelegte Reihenfolge, ich führe sie schlicht so auf, wie sie mir in den Sinn kommt.
Indizien für zerbrochene Fenster sind beispielsweise auffallend lange und womöglich weiter ansteigende Build- und Deployment-Zeiten. Auch Code, der immer öfter Kommentare wie "TODO" oder "FIXME" enthält, sollte Sie nachdenklich stimmen. Wenn Sie regelmäßig Workarounds und provisorische Lösungen umsetzen, anstatt Probleme gründlich zu beseitigen, ist dies ein Warnsignal. Sinkt die Testabdeckung im Laufe der Zeit, treten Fehler erneut auf, die schon einmal behoben worden waren, existiert keine Dokumentation oder ist sie fehlerhaft beziehungsweise veraltet, dann sind das alles Anzeichen für zerbrochene Fenster.
Wenn es Codebereiche gibt, die niemand anfassen will, wenn Ihre Dependencies nicht auf dem neuesten Stand sind, wenn immer mehr Tickets für technische Aufgaben auflaufen – das alles sind Hinweise, dass etwas nicht stimmt. Und all diese Vorkommnisse sind wie Eisberge: Was Sie zuerst sehen, ist immer nur die Spitze, und das wahre Ausmaß bleibt verborgen. Unterschätzen Sie die Lage also nicht, indem Sie sie als unwichtige Kleinigkeiten abtun. Oft ist das tatsächliche Problem viel größer, als es zunächst scheint.
