Software development, .Net, SQL Server, TDD, Agile, Community and other Odds and Sods
Mitch Wheat has been working as a professional programmer since 1984, graduating with a honours degree in Mathematics from Warwick University, UK in 1986. He moved to Perth in 1995, having worked in software houses in London and Rotterdam. He has worked in the areas of mining, electronics, research, defence, financial, GIS, telecommunications, engineering, and information management. Mitch has worked mainly with Microsoft technologies (since Windows version 3.0) but has also used UNIX. He holds the following Microsoft certifications: MCPD (Web and Windows) using C# and SQL Server MCITP (Admin and Developer). His preferred development environment is C#, .Net Framework and SQL Server. Mitch has worked as an independent consultant for the last 10 years, and is currently involved with helping teams improve their Software Development Life Cycle. His areas of special interest lie in performance tuning
Tuesday, October 03, 2006
The Broken Window Effect
Why should you fix a code problem as soon as you find it? If things break, a classic example are unit tests, and they do not get fixed, then other breaks appear and get left broken. This effect has a tendency to escalate to the point where people ignore unit tests, eliminating the benefit that units test provide.
The effect was coined as applied to vacant buildings. As soon as a single window is left broken, others will follow and the effect actually spreads out from the building into the neighbourhood. It is easy to imagine that this effect is real; just apply it to the house you live in. If you leave something that requires attention, you are more likely to leave other things as well (I have experienced this effect first hand!).
This principle of Fixing Broken Windows was documented in the US, and has its critics due to the fact that in society it is hard to eliminate/identify all other contributing factors.
Andrew Hunt and David Thomas used “Fixing Broken Windows” as a metaphor for avoiding software entropy in software development in their book, The Pragmatic Programmer. Next time you are coding and you see something that is broken, maybe you should err on the side of caution and fix it?
(Not to be confused with the Parable of the Broken Window)
MSN, Email: mitch døt wheat at gmail.com