Broken Windows
Autor
Marcus HeldHi,
Vor einer Woche, in meinem Talk “Pragmatic Programming mit Kotlin” , habe ich über die Broken Window Theory gesprochen.
Eigentlich kommt sie aus der Kriminologie.
In criminology, the broken windows theory states that visible signs of crime, anti-social behavior and civil disorder […] encourages further crime and disorder […].
Dave Thomas und Andy Hunt übertragen dieses Bild in die Softwareentwicklung.
Wann immer es ein schlechtes Design, eine unübersichtliche Klasse, schlecht getesteten Code oder ungenutzte Assets im Repository gibt, wird es wahrscheinlicher, dass noch weitere “broken windows” folgen.
Bei einem Kunden konnte ich das in Aktion erleben.
Die Applikation wird seit über 10 Jahren entwickelt. In der Zeit gab es allerlei neue Ansätze, neue Entwickler und neue Prioritäten.
So, wie es immer ist.
Aber in der Zeit wurden broken windows akzeptiert.
Vor einigen Tagen wollte ich herausfinden, wie der Datenbank-Connection-Pool konfiguriert ist.
Also: Volltextsuche.
51 Treffer. Fast ausschließlich .xml
und .properties
files.
Outch.
In dem Repository gibt es natürlich mehr als eine Applikation. Aber keine 51.
Jedes Modul hatte ein eigenes Konfigurationsfile
Welches wird denn nun genommen?
Ich weiß es nicht. Ist das überhaupt deterministisch? Wahrscheinlich.
Aber keine Ahnung nach welcher Regel.
Was aber sicher ist, wir haben hier redundante Angaben. Und dann sind sie auch noch unterschiedlich.
Das ist ein broken window.
Irgendwann hat jemand ein neues Modul entwickelt. Er hat blind alle Konfigurationsfiles übernommen.
Dann muss man sich nicht mit lästigen Exceptions beim Startup rumschlagen. 😕
Dann muss man nicht selbst herausfinden, welche relevant sind.
Aber die Kosten von sowas kommen später.
Und jetzt wird das immer so gemacht.
Alle möglichen Konfigurationen findet man redundant im Code.
Keine Ahnung welche tatsächlich angewendet werden.
Lass keine broken windows zu. Und wenn ein Fenster kaputt ist - repariere es sofort.
Rule the Backend,
~ Marcus