Programming and Broken windows
I was quite fascinated by a simple principle defined by Andrew Hunt and David Thomas in their Pragmatic programmer book derived from the “Broken window theory” in programming. This book was originally published in 1999, but the principles apply to this date. Freakanomics is where I have originally encountered this theory, some years ago. I was probably more interested in the economics part of it then. It is quite brilliant in my view to apply this to software development.
The crux of the broken window theory in it’s original context was that
Disorder causes crime, Crime causes further disorder and crime.
It is not hard to imagine what this would mean in the software world. Imagine a project where there is large code base but has limited tests, when a piece of code is submitted, It is unlikely that the new code being submitted has tests to cover. Compare this to a codebase in the same project and has good unit test coverage, would the same developer submit code without tests? Extremely unlikely. We can extend this to bugs, technical debt, design, quality of pull requests, documentation and everything else that is involved in software development.
So, over sufficient time in projects that are not managed well, a lot of disorder occurs which makes it even more difficult to maintain order later on. Entropy kicks in.
Software entropy
Entropy in physics, defines the amount of disorder in a system. And the amount of disorder tends to reach maximum over time, according to laws of physics. Any software system, if not managed well through the time will tend to “rot”. Bad designs, wrong decisions or just plain badly written code if left unrepaired will cause more disorder and rot.
The most important reason for Software entropy is the culture of the team. It is the mindset of the team, regardless of the size of the team that matters. When the team maintains and fixes the broken pieces at the earliest, the rot naturally reduces. This is precisely the point of the “Broken window theory”, isn’t it?
Don’t live with broken windows
Good teams strive to fix broken windows at the earliest, and will continue to maintain the hygiene of the software. If not possible to fix and some times it really may not possible, at least have a plan and board it up temporarily. But again, the culture if the team tends to frequently resort to boarding up temporarily, then it would end up in the same rot again.
What do you do about existing broken windows?
Let’s say hypothetically (most possibly practically), we are working on a project which has lot of broken windows, what should we do now. One succesful strategy is to aggressively identify all broken windows, board them up, plan “Refactoring”, talk to your boss, the benefits of fixing it have to outweigh. I am not going to talk about how you convince your team, but usually benefits outweigh the cost of effort in long run and you can negotiate a time in upcoming sprint/release for sure.
Go ahead and chalk out a plan to aggressively fix those broken windows now.
Due credit has to go to the authors of this book for this simple and effective insight. If you have not read The Pragmatic programmer book, it is never a bad time to learn from the best.
