Kategorien
Zerbrochene Fenster.
1982 haben die US-amerikanischen Sozialforscher James Q. Wilson und George L. Kelling die „Broken Window Theory“ aufgestellt[1]. Diese Theorie handelt von der Verwahrlosung New Yorks zu der damaligen Zeit. Sie besagt, dass harmlose Verstöße gegen die Norm, wie beispielsweise ein zerbrochenes Fenster, der Beginn sind für den vollständigen Niedergang eines ganzen Systems.
Mögliche Beweise kann man viele finden. So wurde zur Unterlegung der Theorie ein vollkommen intakter Jaguar in die südliche Bronx gestellt. Vier Tage vergingen und das Auto konnte ohne Kratzer wieder abgeholt werden. Keiner kam auf die Idee den Wagen anzufassen oder schlimmeres damit zu machen. Das gleiche Experiment wurde kurz darauf wieder mit diesem Jaguar ausgeführt. Die einzige kleine Schraube an der gedreht wurde, war das Einschlagen eines der kleinen Fenster. Innerhalb von vier Stunden lag das Auto auf dem Rücken, wurde angezündet und ausgenommen. Die Lehre aus diesem Test lautet „Beschädige etwas und kümmere dich nicht darum, andere werden es somit genauso behandeln“. Man muss aber nicht unbedingt ein Auto opfern, um einen Beweis für eine solche Theorie zu gewinnen. Die Beobachtung seines eigenen Mikrokosmos reicht häufig aus. Da wäre die aufgeräumte Wohnung, in der man sich am wohlsten fühlt und die erste Zeit wird man den Teufel tun und irgendwo etwas liegen lassen, sobald aber die ersten Teile nicht mehr auf ihrem Platz liegen findet das Chaos seinen Weg.
Wir als Softwareentwickler kennen dieses Vorgehen nur zu gut. Ist der erste Verstoß gegen die geltenden Regeln erst mal geschehen, so lassen der zweite und dritte nicht lange auf sich warten. Ist das System aber sauber, so tut es uns Entwicklern in der Seele weh, den ersten Fehler zu begehen, denn die meisten erkennen die Eleganz eines reinen Systems.
Es darf nicht vergessen werden, dass es viele Junior-Entwickler in Projekten gibt. Häufig passen sie sich an die Qualität des Codes an, den sie vorfinden. Sollten also keine Kommentare vorhanden sein, so wird er auch keine schreiben. Fehlt die Testabdeckung, so wird sich ein Junior nicht hinsetzen und Unit Tests schreiben. Dafür fehlen meist einfach die Erfahrungswerte und das Wissen, dass diese Eigenschaften von gutem Code einem zum späteren Zeitpunkt weiterhelfen.
Um ein System auf die Dauer sauber zu halten, gilt es möglichst viele Regeln, die man sich gesetzt hat automatisiert zu überprüfen. Es darf nicht passieren, dass sich der Verfall heimlich einschleicht. Ist ein Verstoß erst mal eine Weile im System wird sich niemand mehr verantwortlich fühlen, passiert das Auffinden jedoch zeitnah, so existiert auch noch eine Bindung zum Code.
Regeln die heutzutage einfach automatisiert geprüft werden können sind beispielsweise:
- Formatierungsregeln
- Validierung des Output-Formats
- Einhaltung minimaler Testabdeckung
- Fehlerfreier Testdurchlauf
- Softwaremetriken
Alles was einfach überprüft werden kann, sollte auch gemacht werden.
Bei der Einführung solcher Prüfungen, kann auch sehr viel falsch gemacht werden. Leicht kann der verantwortliche Qualitätsmanager über sein Ziel herausschießen. Sollte zum Beispiel jemand auf die Idee kommen nach dem Lesen dieses Abschnitts die aufgestellten Formatierungsregeln automatisiert zu testen, so ist dies fürs erste eine gute Idee. Wenn der Mechanismus dann das erste Mal durchgelaufen ist, wird man feststellen, dass bereits hunderte von Fenstern eingeschlagen wurden, also viele falsche Formatierungen gefunden wurden. Die Entwickler werden auf diese Art nicht mitgenommen werden. Ob man jetzt 50 oder 51 Probleme hat, ist einem herzlich egal.
Um neue Regeln sauber einzuführen müssen wir das Problem in kleine Häppchen zerlegen und diese dann peu à peu bereinigen. Wir haben neue Formatierungsregeln? Diese müssen vielleicht nur für neuen Code gelten oder wir schalten jeden Monat ein neues Verzeichnis zur Überprüfung hinzu. Wichtig dabei ist, dass der Schmutz, welcher sich über die Jahre gesammelt hat überschaubar bleibt, die Entwickler müssen das Gefühl haben es in einer humanen Zeit hinzubekommen. Wer räumt schon gerne den Müll von anderen auf?
Hi,
Neben den Tools sollte man auf jeden Fall vorschlagen, die Boy Scout Rule in die Teamkultur einzuführen. http://programmer.97things.oreilly.com/wiki/index.php/The_Boy_Scout_Rule (wie so häufig kommt die Idee von Robert C. „uncle Bob“ Martin). Sie sorgt im Gegensatz zu einmaligen Aktionen für eine kontinuierliche Verbesserung des Codes. Und kontinuierlich ist ja genau unser Ding 🙂
Ja gut, das hängt aber auch immer davon ab, ob der Kunde bereit ist zu bezahlen. In der Regel sind die inzwischen Dumping-Preise gewohnt.
Und da man an den Features nicht sparen kann, spart man in der Industrie regelmäßig an Dokumentation und Unit-Tests. Ich habe aufgegeben das in Frage zu stellen: es bringt nichts.
Denn das hat einen rechtlichen Grund: die Budgets. Die sind nämlich fix. Und es handelt sich i.d.R. um Werksverträge. Nach dem Kostenvoranschlag darf man nur um X Prozent überziehen. Und aus politischen Gründen wir der Kostenvoranschlag kleiner angesetzt als der tatsächliche Aufwand und der Druck an die Entwickler weitergegeben.
Also liefert man eine „lauffähige“ Version und korrigiert Fehler nachträglich in einem Folgeauftrag für den es dann wieder Budget gibt.
Wir wissen zwar, dass das der falsche Weg ist. Aber erzähl das mal der Verwaltung eines auch nur mittelgroßen Unternehmens. In der Verwaltung muss alles seine Ordnung haben. Der Prozess war gut genug für Opa, dann ist er auch gut genug für uns. Um Himmelswillen nichts ändern! Die Sekretärin ist gerade froh, dass sie die Grundlagen verstanden hat.
Da könntest du auch versuchen, einen Designer von Photoshop und Powerpoint wegzubringen: viel Glück!
Die Big Bosses haben außerdem gelernt, dass man mit Druck gegenüber der IT Preise senken kann. Dass darunter die Qualität leidet sehen sie nicht mehr, denn sie benutzen ihre eigenen Produkte nicht – sie verkaufen sie nur.
Und Junior Developer hat man grundsätzlich halb so viele wie man bräuchte und die machen doppelt soviel Arbeit wie man sich wünschte. Wenn man heute noch einen Junior Dev findet, der weiß was eine SQL-Injection ist und was der Unterschied ist zwischen einem Interface und einer abstrakten Klasse, dann darf man sich bereits glücklich schätzen. Viele können überhaupt gar kein OOP.
Bei uns schlagen Bewerber auf, die kriegen nicht mal eine einfache For-Schleife zusammen und bewerten ihre PHP-Kenntnisse mit „gut“. Und wir suchen schon 6 Monate im Großraum Frankfurt.
In der Praxis sind ein paar zerbrochene Fenster unser kleinstes Problem. Unser Hauptproblem ist, dass die Kunden keine Kohle für den Glaser ausgeben wollen.
@Tom: Ich arbeite für eine wirklich konservative Firma und selbst wir sind dazu übergegangen Agenturen nicht mehr zu nehmen, die keine Unit-Tests schreiben. Am liebsten arbeiten wir mit solchen, die einen agilen Prozess mit uns leben. So schlimm kann die Welt da draußen also nicht sein.
@Nils, es kommt aber schon ein wenig auf den Buggetpartner an. Es macht nämlich schon einen Unterschied, ob ich ein mittelgroßes Projekt, für einen eher kleinen Kunden baue oder das gleiche Projekt, für ein großes Verlagshaus, wer dem widerspricht ist realitätsfremd oder hat lange nicht mehr mit so kleinen Buden zu tun gehabt…
@Stefan: Da hast du recht, aber meiner Erfahrung nach ist das was man für die kleinen Kunden baut immer ähnlich. Man muss dann auch mal die Rechnung aufmachen, was man an Zeit im zweiten Projekt gespart hätte, hätte man es im ersten gleich sauber gemacht. Wer sich seine eigenen Bibliotheken unsauber aufbaut, der verschenkt sein eigenes Potential.
Wenn man heute noch einen Junior Dev findet, der weiß was eine SQL-Injection ist und was der Unterschied ist zwischen einem Interface und einer abstrakten Klasse, dann darf man sich bereits glücklich schätzen. Viele können überhaupt gar kein OOP.
==
Solche Kommentare machen mir Mut mein Studium durchzustehen. 😉
Spaß beiseite, der Artikel ist wirklich gut und spricht mir aus der Seele. Vor allem in der Webprogrammierung sind „Schlampereien“ ein echtes Problem und leider auf der Tagesordnung.
Ich denke langfristig lassen sich zerbrochene Fensterscheiben nur vermeiden, indem es die Architektur gar nicht erst zulässt.
@kaffeekocher: naja, „Interface“ usw. sind ja auch keine Sachen die ein Junior wissen muss/kann. Ich seh’s ständig wie (inkompetente) Chef/PMs, die alles nur von Wikipedia kennen, selbst vom Praktikanten verlangen daß sie wie alte Hasen arbeiten/coden. Man muss auch mal sehen daß Berufseinsteiger/Juniors heutzutage meist kein 5-jähriges Diplomstudium mehr hinter sich haben sondern viel früher in de Job starten bzw. als Quereinsteiger/Selftaught in den Job kommen. Viele PHP-Coder waren mal Grafiker, JSer, Mediengestalter (auch so’n Thema, der PHP-Part der offiziellen Ausbildung ist die Katastrophe !) usw.
Dazu der leere Jobmarkt.
@all: Schlampigkeit kommt sicherlich auch vom Zeitdruck und Entnervtheit. Wenn du zum 20x alles ändern musstest (traurig, sinnlos, aber leider Realität aufgrund völlig inkompetenter Projektmanager/Vorgesetzer, die nicht die geringste Ahnung haben), und dann um 22:00 immer noch im Büro sitzt, c’mon, da schreibst du einfach keine comments mehr oder denkst über bestmögliche Lösungen nach. Hauptsache den Scheiss vom Tisch haben, es gibt ja auch noch wichtigere Sachen im Leben als den Job (!).
Im Übrigen ein erstklassiger Artikel !
Hi,
danke für den guten Artikel. Werde von nun an öfter hier schreiben.
@Tom:
Was sollte denn ein Junior können? Da kommen echt Leute, die noch nichtmal ne For-Schleife anwenden können. Das ist schon sehr übel.
Solche und ähnliche Tipps gibt es auch im Buch
„Der Pragmatische Programmierer“ von Andrew Hunt und David Thomas.
Wer weiterhin Waterfall Programmierung verkauft kann auch nicht wirklich Testing und Documentation verkaufen. Da hofft man doch am Ende blos, wenigstens 70% der Features noch umzusetzen zu können in 3 Monaten.
Wer von Anfang an Agile Softwareentwicklung verkauft, kann dem Kunden sicherlich besser in-time 80% seiner wichtigsten Features liefern! Die letzten 20% sind dann oftmals zum Teil doch überflüssig oder doch noch wichtig und lassen sich einfach integrieren. Der Kunde muss aber nicht zweieinhalb Jahre auf sein Produkt warten und ist froh, oft Updates zu bekommen mit Bugfixes und neuen Features.
Bei den Beispielen geht es einfach um Unternehmeskultur als darum, wie der „Markt“ derzeit funktioniert. Beide Typen finden Auftraggeber. Erstere werden öfter die Ziele verfehlen. Siehe auch https://gist.github.com/710960 😉
Aus http://pragprog.com/the-pragmatic-programmer/extracts/tips:
„Don’t Live with Broken Windows
Fix bad designs, wrong decisions, and poor code when you see them.“
Alle rules ausdrucken und am besten an die Klotür im Büro kleben 😉 Dann kann ja eigentlich nix mehr schief gehen…
@Tom
ich hoffe ich darf dich zitieren:
An der Qualität zu sparen bringt immer Probleme.
Dem Vorgesetzten sage ich Folgendes: man kann nicht alles haben. Features, Zeit, Ressourcen und Qualität sind gegenläufige Ziele.
Qualität sollte dabei die einzige Konstante sein, denn Qualität ist es wodurch man sich von der Billigkonkurrenz unterscheidet.
Entwicklungsphasen und Tests kürzen? Spart momentan ein paar Stunden, erhöht aber schleichend und auf lange Zeit das Geschäftsrisiko und führt zu einem schleichenden Wertverlust des Stammkapitals. Es vergiftet schleichend den wertvollen Code-Pool der Firma aus dem der Schäfer der Herde seine Jünger tränkt, bis ihnen die Wolle ausgeht und sie keine Milch mehr geben. Bei Firmen endet das am Ende stets in der Notschlachtung.
it has slipped your mind? 🙂
@miasin: Danke.
@miasin: Danke Dir auch 🙂