Programming and Broken windows

The crux of the broken window theory in it’s original context was that

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.

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?

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.

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.

Related posts:

Before jumping the horse, you may ask — what is identity? I have previously been introduced to the concept of identity in the past through similar learning areas. Identity has a different meaning for…

Memulai sesuatu memang tidaklah mudah, apalagi bila datang tak menentu dari prediksi. Memulai lagi-lagi tidak hanya modal berani, namun konsistensi adalah titik awal yang bisa dikatakan sulit untuk…

Agile is a popular project management method that prioritizes flexibility and collaboration in software development. One aspect of agile that is often overlooked is the importance of having a hacker…