Among many of my interest areas over time, one constant domain has been urban design and how it can foster communities; so when I came across an article from 1982 it immediately caught my eye. Read this excerpt:
Social psychologists and police officers tend to agree that if a window in a building is broken and is left unrepaired, all the rest of the windows in the neighborhood will soon be broken.
This is as true in nice neighborhoods as in run-down ones. Window-breaking does not necessarily occur on a large scale because some areas are inhabited by determined window-breakers whereas others are populated by window-lovers; rather, one unrepaired broken window is a signal that no one cares, and so breaking more windows costs nothing.
Now this is interesting; the impact of such psychology is still very much prevalent and wide-ranging. Complacence breeds incompetence, incompetence leads to neglect, and neglect eventually results in the failure of systems. When people stop caring about the things they value, eventually other people mirror the same.
Interactive communities wither away when people stop showing up, relationships go sour when one person stops caring, businesses go bust when they stop innovating their products, and code-quality eventually degrades when software-engineers know that feature delivery is a much valued KPI over general code-quality and optimizaton.
When engineers decide to be lax with the software they write, it is because someone else decided to slack in the first place. This eventually spills over to the rest of the code in the project, and the entropy/chaos in the system keeps increasing over time. Negligence finds a way, and eventually more windows get broken.
I see three ways to ward-off this ‘window-breaking’ when it comes to software:
- Set Benchmarks & Standards. For setting pole-stars for the project. Templates and guardrails.
- Incentivize. Reward clean and optimized code now over bug-fixing it later. Avoid the cobra effect.
- Tight Feedback Loops. Avoid buildups of both emotions and poor code. Let others know of poor-quality immediately rather than complain about it later.
When engineers start taking ownership of their code like proactive members of a nice neighbourhood, the occurances of crimes-against-code or window-breakings will go down as well, and more people would like to be a part of your community.
I have been guilty of using this analogy in the past, but it must be said that basing an argument on this racist and empirically false notion of social disorder hurts your argument more than it helps.
Agreed, it also seems more time is spent on the analogy here than the core message of the text.
As someone who has never been the owner of a project with multiple developers, a lot of knowledge is assumed here that I don’t actually have. What specific problems are afflicting open source projects that result from being lax and not caring enough?
With regard to the suggested solutions, how does this look exactly? Benchmarks and standards are fairly self explanatory, templates and guard rails less so. How does one go about incentivising and rewarding good code? I know what the cobra effect is but others might not. What are feedback loops and how can they be tightened?