Broken Windows

There’s a theory that says that where small indiscretions are ignored, larger ones will follow. The theory, known as the “broken window” effect, is most often illustrated using crime as an example. The argument says that if a building has broken windows and those windows are left unattended, the presence of the broken glass will encourage vandals to break more windows. If repairs are still not carried out, the message to the community is that no one really cares and that then leads to an escalation in lawlessness. The underlying theory says that if small concerns (such as broken windows) are addressed quickly the community will avoid more serious crimes.

One organization I worked with provided the opportunity to see an interesting corollary. The organization had two development teams, each with its own technical lead. The two technical leads had very different approaches. One was very quality conscious and believed that ensuring decent development practices was a part of their role. The second took a more laissez-faire approach and as long as people delivered on schedule there was no need for any form of oversight.

The different philosophies resulted in very different leadership styles. In a parallel to the broken glass theory, the quality oriented lead believed that if a blind eye was turned to quality issues, those quality problems would lead to a further degradation in quality standards. As a result they took it on as a part of their role to not only keep an ongoing discussion about quality practices alive, but also to have private conversations with developers who he felt had violated basic principles of sound development.

The reason this story interests me, is that the organization had some hard data that potentially illustrates the broken glass effect in the context of software development. As part of their on-going tracking of service level agreements, the organization tracked the number of defects that made it through to their production system. As part of my work with the organization we carried out some analysis of the available data. The results showed that relative to the second team, the team that placed a focus on quality practices;

  1. Incurred 50% fewer production defects
  2. Produced 30% more code (source lines of code)

In addition and perhaps even more illuminating is that prior to the arrival of the quality oriented technical lead, the performance of the two teams was approximately the same. Could there be other explanations for the differences, absolutely, but it does warrant a discussion as to how leaders influence the behaviours of their teams.