Broken windows and boy scouts

Today, our Akeneo PIM product is made of ~200k lines of PHP code and ~50k lines of Javascript code.

The product is customized in projects by solution providers to answer to the very specific business needs of final customers.

I recently had the opportunity to do a feedback talk during the PHP Forum in Paris about almost 3 years experience of building an Enterprise Software.

There is a focus on a small part of this talk about how do we take care of our continuously growing code base.

The “broken windows theory” is a criminological theory, which explains that you must prevent small crimes to avoid more serious crimes to occur.

Let’s assume I park my car in a specific place and come back 2 weeks later, there is big probability that nothing happened to it. Let’s now park my car in the same place, break a window (yeah I know, it’s weird) then come back 2 weeks later, there is now an important probability that my car has been more damaged or even worst, stolen.

One explanation is that for all people passing around during these 2 weeks, nobody really care of this car which is broken and still broken the day after, a bit more damaged is not such a big deal.

It’s quite easy to do the analogy with our code base. If the whole team passes through an ugly part of code (complex, not understandable, etc) and nobody fixes it, we can quickly conclude that nobody cares of it.

So when someone has to change a bit the logic or fix this code, make it a bit uglier is not serious, anyway, nobody will pay attention.

A famous boy scout rule can be summarized by : “always leave the campground cleaner than you found it”.

Idea is the same with the code, as developers, when we’re working or using something, we always try to leave it cleaner than when we arrived on.

I’m not talking about large re-writing but more about very simple actions, as extract a couple of private methods from a complex public method to make it more understandable, re-work a bit a naming, add a missing unit test to make explicit a weird covered case.

Fixing small broken windows is important, it clearly sends a strong and loud message to the followers : “this code is important for me”. It also gives us a cleaner place to work and allows to slow down the software entropy.

Obviously, this practice does not solve larger technical debt issues, we’ll hopefully write soon a story about how we try to achieve bigger technical changes.

An now, let’s be a boy scout and repair some broken windows!