Richard Hart

Head of Something @ Somewhere
Kent, UK

My Music
My Photos

LinkedIn
Mastodon

Broken Window Policy of Programming

There comes a point in every software projects life where everything just feels wrong. No one wants to touch the code as it stinks and everyone working on the project just feels demotivated and would rather just go home then have to do anything more on it. On projects like this, when it comes to adding new features or bits of code, because everything else is such a mess, the changes are just hacked in rather than being properly thought out and coded up well.

We’ve all been there and the frustrating thing is that our opinion of the project, from good to bad, seems to happens over night. If you sit down and think back, you can probably pick out all the things that were just shoved in that eventually led to the project becoming a mess, but at the time we never chose to do anything about. It’s almost always a case of deferring better solutions or a round of refactoring to some point in the future. “I’ll knock this up now and come back to it later.”. The problem is that later never comes. This is the essence of technical debt. You may only go into debt by a fraction, but do it a few times and eventually all those fractions add up. Until one day when you go to check your balance, you find yourself swimming in the middle of the ocean with no land in sight.

Implementing a broken window policy can go a huge way towards keeping a project healthy. If there is a broken window (bad code) fix it as-soon-as-possible. It doesn’t have to be that instant (although if you can, you should), but fix it. Part of the policy also means trying not to break windows yourself. Write the best code you can, as often as you can. Set the benchmark of quality for the rest of the team, even if they don’t follow suit. The danger is that many people are very “me too” about things. “Well if such-and-such can do it like this, then so can I *hack* *hack* *hack*”.

Of course we all write crap from time to time. TBH most of the stuff I write is crap. But I honestly feel more motivated to work on code that’s been loved and looked after, rather than something that’s hanging together by a thread.