Broken Windows
Find the English version below
Hi ,
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
English
Hi ,
A week ago, during my talk on "Pragmatic Programming with Kotlin", I discussed the Broken Window Theory.
Originally, it's from criminology.
In criminology, the broken windows theory states that visible signs of crime, anti-social behavior, and civil disorder […] encourage further crime and disorder […].
Dave Thomas and Andy Hunt have applied this concept to software development.
Whenever there's poor design, an unclear class, inadequately tested code, or unused assets in the repository, it becomes more likely that more “broken windows” will follow.
I witnessed this in action with a client.
The application has been in development for over 10 years. During that time, there were various new approaches, new developers, and new priorities.
As it always is.
But during that period, broken windows were accepted.
A few days ago, I wanted to determine how the database connection pool was configured.
So: Full-text search.
51 hits. Almost exclusively .xml
and .properties
files.
Ouch.
There are naturally more than one application in the repository. But not 51.
Each module had its own configuration file
Which one is actually used?
I don't know. Is it even deterministic? Probably.
But I have no clue based on what rule.
What's certain, though, is that we have redundant information here. And they are also different.
That's a broken window.
At some point, someone developed a new module. They blindly copied all the configuration files.
That way, you don't have to deal with annoying exceptions during startup. 😕
You don't have to figure out which ones are relevant.
But the costs of such actions come later.
And now, it's always done that way.
All possible configurations are redundantly found in the code.
No idea which ones are actually applied.
Don't allow broken windows. And if a window is broken - fix it immediately.
Rule the Backend,
~ Marcus