Software Development and the Broken Windows Theory

There is a theory called the “Broken Windows Theory“. This theory states that if there is a disorder in a neighbourhood for a substantial period of time, the mess will only get worse. The authors give the example of a broken window in an abandoned building. If it isn’t replaced within some time, the chances are that vandals will break another window. And another. Gradually making the mess worse, and therefore making the issue bigger.

How the broken windows theory relates to software development

This theory applies to quality in software development as well. Over time the quality of our software may decrease for a variety of reasons. For instance, when under the pressure of a deadline we tend to do concessions to the quality of our software. Or when some tests fail, and no-one acts, it doesn’t motivate to write good tests and more tests will fail over time. Effectively making the testsuite useless. This disorder is also known as technical debt.

How it works

The mechanic about this effect is that you unconsciously and gradually lower the norm of quality of your software. This is of course not what you want for your customer. But also for your team.
Not responding to the “broken windows” in your project will effectively change the mindset about quality, and it leads to passive/reactive behaviour. Do you know that feeling that you’re constantly running into problems with existing code? Then you might have had some broken windows for too long!

Fix the windows!

The broken windows theory in full effect
©2012 iStockphoto

The solution that the broken windows theory describes is to actively monitor and report any disorder like a broken window, litter, holes in the road, or graffiti. In software development their equals would be poor code, bugs, failing tests, or bad design implementations.

The key to success is to maintain a zero tolerance policy on technical debt. And to clean up the list of disorders within a timely fashion.
Of course, you and your team have to decide on what you consider technical debt within the project. This will usually be affected by customer expectations and/or budget. But make sure you all agree on what the quality standard is. Otherwise maintaining a zero tolerance policy will be ineffective, and may cause frustration.

It’s in your hands

Implementing this strategy is something you can start doing today. If you start pointing out and act to the so-called technical debt, you will soon start a movement within your team. You will create awareness and team members will follow your example. Social control on the subject will grow, which encourages to stick to the set quality standards.

Ultimately leading to a better product, happy teams, and happy customers!

Anticipating for change with the Strategy-pattern

We developers get to deal with change nearly every day. As your project progresses, stories or requirements are changed or added. And we’ve all been to the point where our code gets brittle or unmaintainable after too many changes and/or additions.

Let’s start with a metaphor. Let’s say your keyboard is broken and you need a new one. Luckily the keyboard is connected via a USB-connector to your computer, so you can replace it with another keyboard with ease.
But what if there wasn’t a common interface (USB) to connect your keyboard to a computer, for example if it was directly connected to the computer?
Indeed, you would either get an entire new computer or you’d be soldering your new keyboard onto your computer. None of which are ideal solutions to the problem.

This metaphor applies to programming in many ways, but arguably the most important principle that comes from this example is that you should program to an interface where possible.

In a lot of cases programming to an interface encourages the interchangeability of certain parts of your application. Thus it enables you to write flexible code, and anticipate for changes in domain logic.

If you’ve ever written or worked with an online shop you might have come a cross the problem that different countries have different tax rates. Each country has their own tax rate, which of course can change independently. When implementing an online shop, this problem cries out for a flexible solution, and you need to think of a durable strategy to solve this problem.

Diagram 1 - Different implementations of TaxInterface

A good way to do this is to look for commonalities of the different calculations. It is not hard to see that every tax calculation has nothing more than an in- and output number. As long as the tax is calculated correctly, the calculation itself is not really important to the system.
These commonalities are the things you define in the interface, in this case we’ll call the method calculateTax. By programming each country-specific implementation to the interface (TaxInterface) the Order does not need to know (or worry) about the outcome of TaxInterface::calculateTax(). The only thing that it needs to do is instantiate the approperiate implementation, which is out of the scope of this post.

See Diagram 1 for a clarification.

This solution is defined as the “Strategy pattern”, and it is about anticipating on (potential) change of features. In the example it is fairly easy to add a tax implementation for another country, while you have to make only small changes to your existing code.

I hope this example demonstrated the reason behind programming to an interface and and the purpose of the Strategy-pattern in a fairly simple manner.