“Wehret den Anfängen!” oder the experience of „no one is caring“!
Die #Broken Windows Theroy ist ein von James Q. Wilson und George L. Kelling geprägter Begriff für ein sozialpsychologisches Phänomen. Dieses gelang in der Kriminalistik zu Berühmtheit, weil es zu New Yorks “Zero Tolerance“ Politik in den 1990er Jahren führte.
Der Theorie nach stehen Unordnung und Kriminalität in einem ursächlichen Zusammenhang. Es reicht ein kleiner Auslöser, um eine folgenschwere Kettenreaktion in Gang zu setzen. Als Symbol hierfür verwenden sie das Bild vom ersten zerbrochenen Fenster eines Hauses, das nicht ausgetauscht wird. Das erste zerstörte Fenster löst die Vorstellung aus, dass es niemanden stört, wenn auch ein zweites Fenster zerstört wird. In der Folge werden weitere Fenster des Hauses zerstört und Farbschmierereien angebracht. Anschließend überträgt sich der Verfall auf die anliegenden Häuser und Straßen. Dies trifft für schlechte, wie gute Wohnbezirke zu.
Die Ersteller der Theorie sehen den Täter als eigenverantwortlich handelndes und sich bewusst für abweichendes Verhalten entscheidendes Wesen an. Der Täter fällt seine Entscheidung nach einer Kosten-Nutzen-Abwägung, wobei die Entscheidungshürde sinkt, wenn bereits ein Fenster kaputt ist. Des Weiteren erhöht Anonymität die Geschwindigkeit der Zerstörung / Verwahrlosung.
Dem Verhalten wird entgegen gewirkt, wenn die Entdeckungs- und Sanktionswahrscheinlichkeit für das Begehen der Tat erhöht werden.
Wie sich die Broken Window Theory auf die Softwareentwicklung auswirkt
Diese Theorie ist auch auf Softwareentwicklung anwendbar. Programmieren ist extrem detailorientiert und komplex in der Wirkung. Im Laufe der Zeit kann die Qualität unserer Software aus verschiedenen Gründen abnehmen. Wenn wir beispielsweise unter dem Druck einer Frist stehen, neigen wir dazu, Zugeständnisse an die Qualität unserer Software zu machen. In der Konsequenz schlagen „unwichtige“ Tests fehl und niemand handelt. Diese Tests erhöhen dann die technische Schuld. Dies ist das erste zerbrochene Fenster. Die Testsuite ist nun fehlerhaft und wird aus Zeitgründen eher deaktiviert als repariert. Qualitätseinbußen werden akzeptiert. Diese Akzeptanz ist nun im Entscheidungsverhalten von Entwicklern verankert und wirkt auch bei der Qualität der Tests, als auch der Häufigkeit der implementierten Tests. Testabteilungen schlagen dann Alarm und es kommt zu Frontenbildung und Verzögerungen.
Wie es funktioniert
Der Mechanismus dieses Effekts besteht darin, dass Sie die Gruppennorm für Qualität der Software unbewusst und schrittweise senkt. Wenn in einem Projekt nicht auf die „zerbrochenen Fenster“ reagiert wird, ändert sich die Einstellung zur Qualität effektiv und es kommt zu passivem / reaktivem Verhalten aller „beheimateten“ Teammitglieder. Wer das Gefühl kennt, ständig mit problembehafteten Legacycode zu arbeiten, wird vielleicht mit Code arbeiten, bei dem zu lange das zerbrochene Fenster nicht repartiert wurde.
Repariere die Fenster!
Die Lösung, die in der #Broken Window Theory beschrieben wird, besteht darin, bestehenden Code ständig und aktiv auf Auffälligkeiten zu prüfen und diese zu melden. In der #continuous Integration prüft man z.B. fehlgeschlagene Tests und Codeabdeckung. In #Reviews werden Designimplementierungen, Codequalität und das Einhalten von Codierrichtlinien geprüft.
Der Schlüssel zum Erfolg liegt in der Aufrechterhaltung einer Null-Toleranz-Politik für technische Schulden auch in zeitkritischen Situationen. Natürlich muss im Team entschieden werden, was als technische Schuld innerhalb des Projekts betrachtet wird. Dies wird normalerweise von den Kundenerwartungen und / oder dem Budget beeinflusst. Es muss sichergestellt sein, dass sich alle über den Qualitätsstandard einig sind! Andernfalls ist die Einhaltung einer Null-Toleranz-Richtlinie unwirksam und kann zu Frustration führen.
#Feature Driven Development hilft sehr, da es den Test nicht am Ende des Projekts „abarbeitet“ sondern während der Feature-Entwicklung auf Einhaltung achtet. Mit dieser Entwicklungsart fällt möglicherweise ein Feature in den nächsten #Release Train, gleichzeitig besteht jedoch kein Qualitätsrisiko für das Produkt.
Es liegt in Euren Händen
Mit der Umsetzung dieser Strategie kann sofort begonnen werden. Der erste Schritt ist das aktive Hinweisen auf technische Schulden, der Zweite auf diese Hinweise zu reagieren. Werden beide Schritte gegangen, wird eine Bewegung innerhalb der Teams beginnen. Ein Bewusstsein wird geschaffen und die Teammitglieder Folgen dem Beispiel. Die soziale Kontrolle nimmt zu und ermuntert, die festgelegten Qualitätsstandards einzuhalten.
Letztendlich führt dies zu pünktlichen Releases, zufriedenen Teams, einem besseren Produkt und zufriedenen Kunden.
Unsere Tipps um kaputte Fenster schnell zu reparieren
- Dezentralisierung von Verantwortung in die Teams
- Aktives Messen von Codequalität in CI und Reviews
- Handlungsplan erstellen
- konkrete Maßnahmen zur Verbesserung durchführen
- Erfolge feiern
- Nur Regeln aufstellen, die eingehalten werden können. Sinnlose Regeln werden schneller gebrochen, müssen erkannt werden, denn sonst beschleunigen sie den psychologischen Prozess.
- Feature Driven Development mit DoR und DoD einführen
