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 […].

~ Wikipedia

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