"Broken Window" Theorie in Softwareprojekten

Die Broken-Windows-Theory bezeichnet ein in den Vereinigten Staaten entwickeltes Konzept, das beschreibt, wie ein vergleichsweise harmloses Phänomen, z. B. ein zerbrochenes Fenster in einem leerstehenden Haus, später zu völliger Verwahrlosung führen kann.

Das ist der Einführungssatz zum Artikel zur Broken Window Theorie auf wikipedia.
Ich habe letztens mit einem Freund, mit dem ich auch sonst zusammenarbeite darüber diskutiert, wie schon kleinbar kleine Schlampereien in Softwareprojekten mit vielen Beteiligten zu genau dem in der Broken Window Theorie beschriebenen Effekten führen kann.
Ausgangspunkt war ein neuer Kollege, der zu einem unserer Projekte dazugestossen ist und der zielsicher all unsere unsauber umgesetzten "egal, lass uns das schnell machen" Stellen gefunden hatte und diese sich als Beispiel suchte.
Als nächstes kam ein bisschen Zeitdruck dazu und der nächste Entwickler stiess auf diesen Bereich und sagte sich scheinbar "uh hier siehts ja aus"...und nahm das als Anlass ebenfalls nicht besonders grosse Sorgfalt walten zu lassen.
Lange Rede kurzer Sinn...auch ein kleines eingeschlagenes Fenster kann zum Verwüstung ganzer Stadtviertel führen.
In unserem Fall dank RefactoringSession wieder abgewendet...
Auch wenn die Faktoren für den Niedergang andere sind, gibt es in der Auswirkungen entfernte Ähnlichkeit.
So long...
Maxx

Oh weh... da werden Erinnerungen wach...
Beruflich hatten wir mal ein Projekt, was über 7 Jahre laufend erweitert wurde. Programmiert in ASP (nicht ASP.NET), es mußte immer alles schnell schnell schnell verfügbar sein, jeder Versuch auf neue Techniken zu schwenken wurde verneint... Resultat... das Tool läuft, aber wir brauchen 5 Programmierer um die Wartung zu packen.
Bei meinen eigenen Projekten... hach wie schön hat KoKa Anfangs funktioniert. Sauberer Code, wenig Bugs und dann hörte ich auf die Userwünsche.
Hier mal was eingebaut, da mal was gemacht, hach da hab ich heute keine Lust zu... das Ergebnis... der Source ist desolat, ein versuchter Restart ist nach wenigen Wochen von mir abgebrochen worden, weil ich mehr Zeit im Bughunting verbringen mußte, als ich für das Coden selbst hatte.
Deshalb... lieber einmal mehr Arbeit in die Sache gesteckt und sauber gearbeitet, als schnell mal ein neues Feature eingebaut.

Kommt mir auch recht bekannt vor.
Wenn es mal schnell gehen muss, sieht der Code schnell mal unsauber und unübersichtlich aus. Dann denk ich mir immer: Okay den tust demnächst mal überarbeiten.
Natürlich ist das "demnächst" meist nicht wirklich demnächst. Wenn ich dann mal wieder an der Stelle arbeiten muss, dann kommt der Gedanke: ach wollte ich eh überareibeten... und so wird die Stelle weiter unsauber erweitert.
Aber hey ich habe noch all diese Stellen im Kopf und einige schon ausgebessert.
Was bleibt ist trotzdem eine Mehrarbeit, denn mit unsauberem Code gebe ich mich nur ungern zufrieden.

Das ist meiner Meinung nach ein völlig normaler Vorgang, der sich spieltheoretisch einfach erklären lässt. Solange jeder Beteiligte sich um Ordnung kümmert (keine Fenster einschlagen, kein quick-and-dirty Programmieren, keine Schlammschlacht im Wahlkampf, ...), profitieren alle davon, der "Gesamtgewinn" ist maximal. In der Spieltheorie wird das mit "cooperate" bezeichnet. Sobald aber ein Teilnehmer dies nicht mehr tut (was für ihn eine bessere Strategie ist: Er hat den Aufwand fürs saubere Programmieren nicht, er kann dem anderen Kandidaten schaden, ...), - "defect" im Jargon - lohnt sich für die anderen das kooperieren nicht mehr. Sie haben den Aufwand, aber nicht mehr den Nutzen. Also gehen auch sie zu "defect" über, und das System geht in einen Gleichgewichtszustand über, wenn auch einen ungewollten. Das ist eine verallgemeinerte Version des Gefangenendilemmas (mich wundert, dass der Wikipediaartikel nicht darauf verweist...).
Interessanterweise gibt es - sowohl spieltheoretisch, als auch angewandt - Methoden, um das Problem zu umgehen (bzw. es hinauszuzögern, oder wieder in den Ursprungszustand zu kommen). Das Nulltoleranzmodell der New Yorker Polizei ist so ein Beispiel. Damit werden die Kosten für "defect" dermaßen erhöht, dass es sich nicht mehr lohnt, diese Strategie einzuschlagen. Der gewünschte Zustand wird damit ein Gleichgewichtszustand. Jedenfalls in der Theorie.
In einem Softwareprojekt kann man vielleicht so was ähnliches einführen. Wer bei "mal-eben-schnell" erwischt wird, zahlt auf dem nächsten Treffen (sowas habt ihr doch, oder?) für jeden Tag des Bestehens des Problems eine Runde. Damit dürfte genügend Toleranz bleiben, wenn sowas wirklich mal nötig ist, aber die Kosten sollten eine dauerhafte Verwahrlosung vermeiden. Theoretisch ;-)

Wenn alle mitmachen, führt das unter dem Strich nur zu einem massiven Besäufnis

Habe ich selbst schon gemerkt.
Daher versuche ich 'objektive' Tools wie FxCop oder SourceCop zu nutzen, die die Qualität des Quellcodes bestimmen.
Natürlich werden dort keine organisatorischen oder logischen Probleme beurteilt, aber Qualität fängt in meinen Augen beim kleinen an.

will ja keine werbung machen ,
aber in einem meiner letzten blogeinträge
spreche ich das thema an
auch wenn TheUndeadable sehr von .NET ausgeht, auch für Eclipse
gibt es eine Art Qualitätssicherung

Ausgangspunkt war ein neuer Kollege, der zu einem unserer Projekte dazugestossen ist und der zielsicher all unsere unsauber umgesetzten "egal, lass uns das schnell machen" Stellen gefunden hatte und diese sich als Beispiel suchte.

QmQs ist mittlerweile ein anerkannter Beruf, Unit-Tests mal so als Wort hineingeworfen
aber für jeden der wie ich in java (jsp) entwickelt, gibbet 3 regeln
1.) an Standards halten
2.) an Standards halten
3.) an Standards halten
ich weiss dass es für winzigweich(M$) nur einen Standart gibt (den eigenen)
aber definiert Interfaces, Superclasses usw, die Teamarbeit ist dann einfacher

Undead...benutzt du diese Tools regelmässig? Was sind da deine Erfahrungen?
Ich habe mal Hammurapi ( www.hammurapi.biz/ ) zur statischen Codeanalyse von einem Java-Projjekt an dem ich beteiligt war benutzt, jedoch nur mit mässigem Erfolg.
Bei uns lag der Schwerpunkt jedoch auf Quality Assurance...mithilfe der Analyseergebnisse wurden potentielle Einstiegspunkte gesucht um dann manuell nach Schwachstellen zu suchen.
Maxx

> benutzt du diese Tools regelmässig? Was sind da deine Erfahrungen?
Nicht wirklich, das muss ich zugeben.
Dadurch, dass diese Tools verdammt strikt sind und gerade die Umstellung von Altprojekten sehr zeitaufwändig ist (bis zu 100 Warnings pro Klasse), setze ich diese Tools nur punktuell bei wichtigen Routinen ein.
Die von mir genannten Tools sind Top. Sie finden viele Programmfehler, einige Sicherheitslöcher und viele unnötige Performancefallen. Die Sourcecodeanalyse habe ich erst vor etwa 14 Tagen entdeckt (wurde vor etwa 1 Monat veröffentlicht) und bin da selbst noch am evaluieren. Wahrscheinlich werde ich aber die Vorschläge bei allen Neuprojekten soweit wie sinnvoll umsetzen.
Da ich zum großen Teil Projekte allein umsetze, kosten mich diese Tools mehr Zeit als sie mir direkt nutzen. Würde ich 100% kommerziell Projekte bauen, würde ich diese Tools zum Standard machen. (Allerdings würde ich so manche ultrapeniblen Überprüfungen deaktivieren...)
MS selbst nutzt FxCop und SourceCop und deren Quellverwaltungssystem verweigert Check-Ins, die gewisse Richtlinien nicht erfüllen. Dazu fehlen auch 'weiche' Faktoren, wie Anzahl von Verschachtelungen, Zeilen pro Funktion, etc...
blogs.msdn.com/fxcop/archive/2007/08/09/what-rules-do-microsoft-have-turned-on-internally.aspx
blogs.msdn.com/fxcop/archive/2007/10/03/new-for-visual-studio-2008-code-metrics.aspx
Diese Tools gibt es meines Wissens nach auch für jede andere Laufzeitumgebung und es ist IMHO wichtig, dass man objektive Tools hat und nicht nur nach Gutdünken arbeitet.
FxCop ist zwar kostenlos, aber die Code Metric-Prüfung für VS kostet einiges (Visual Studio Team Edition...).
Zusammengefasst:
Von mir sind etwa 5 bis 10% meines Codes 'geprüft'....
@fkdmatze: Aus deinem Blog:
"Oder ihr seit einfach nur Doof"
seitseid.de

Gibts denn für PHP auch solche Tools? Hört sich recht interessant an.

Ich kann von mir sagen, daß ich sowohl FXCop, als auch NUnit und NCover regelmässig nutze. Leider ist bei letzterem die Demo abgelaufen und ich muß wohl langsam mal mich drum kümmern eine Vollversion zu kaufen.
Checkins mache ich keine... irgendwie komme ich Privat schon immer ohne Sourcecode Verwaltung aus. Liegt wohl auch daran, daß ich mir mit SVN schon öfterst bei Tests, ganze Sourcestämme vermurkst habe. Bin halt ClearCase gewohnt

Original von MrMaxx
Undead...benutzt du diese Tools regelmässig? Was sind da deine Erfahrungen?
Ich habe mal Hammurapi ( www.hammurapi.biz/ ) zur statischen Codeanalyse von einem Java-Projjekt an dem ich beteiligt war benutzt, jedoch nur mit mässigem Erfolg.
Bei uns lag der Schwerpunkt jedoch auf Quality Assurance...mithilfe der Analyseergebnisse wurden potentielle Einstiegspunkte gesucht um dann manuell nach Schwachstellen zu suchen.
Maxx

Im Java-Magazin 3/08 gibt es einen netten Artikel zu dem Thema Code-Qualität Messung. Da gehen die auf ein paar Tools ein, mit denen man JavaDoc-Abdeckung, Abhängigkeiten zwischen Modulen, Coding-Standads, u.ä. messen kann. Diese Tools kann man in den build-Prozess einbinden und sich Reports erzeugen lassen. Dazu kann man dann auch eine Historie pflegen, um die Entwicklung der Qualität des Codes über die Zeit zu verfolgen.
Habe damit schon bisschen herumexperimentiert, ist auch echt nett, was man da angezeigt bekommt. Aber nur Reports haben nutzt nix, man muss die sich auch regelmäßig angucken, und man muss da auch an einer Menge Schrauben drehen, um zu vernünftigen Ergebnissen zu kommen, und eben nicht 100 Warnings pro Klasse angezeigt zu kriegen.
Das ist ne Sache, da könnte man in nem großen Projekt eine Person alleine nur für die Überwachung der Code-Qualität abstellen, entsprechend lohnt das für uns wohl nicht (außer man macht das zum Skillen)
Gruß Michael

Sehe ich auch so. Wir haben jeweils am Freitag nachmittag den Code der anderen (Wurde aus gewürfelt wessen) durchgesehen. Derjenige durfte dann erst heim wenn der eigene Code unseren (recht hohen) Standards entsprach.
Am Anfang recht schwierig, half aber Kunstgriffe und "ich mach mal schnell" abzuschaffen, was in einem Projekt bei dem von 5 Mitarbeitern 3 Praktikanten sind auch dringend notwenidg war.
Es gab auch ein Script, da trifft das Broken-Window absolut zu. Alleinschon weil eine weitere zerbrochene Fensterscheibe dann gar nicht auffällt, wenn es schon 20 davon gibt. Da hilft dann nur eine Komplettrenovierung oder ein Neubau.