Broken Windows
When I read about broken Windows in the Pragmatic Programmer, I could immediately identify with the concept as I had experienced a similar downward spiral in projects I had been a part of.
While reviewing a PR lately, I saw a seemingly harmless line of code:
To the discerning, you may notice that the added line of code looks somewhat off. To some, it may look like something we could safely ignore and approve the PR. That line of code is a symptom of a bigger problem. A little back-story:
The developer added that endpoint to be able to return all the roles within the application as key-value pairs. According to standard REST architectural guidelines and as highlighted by Richardson's Maturity Model — Level 2, the/roles endpoint should be able to do that. So why did the developer not use the /roles endpoint and use a parameter to indicate the format the data should be returned in, E.g
/roles?format=object
The short answer: The index method was poorly designed. These leaves us with two options:
- Just ignore and approve the PR
- Do the right thing - rewrite the index method to work as expected and change the code that's dependent on it (Project not live yet)
Option one looks simple and harmless but according to the Broken Window theory, that means the next developer that comes by will add to the technical debt, effectively leading to a brittle and hard to maintain code base.
Excerpts from The Pragmatic Programmer summarises this concept:
In inner cities, some buildings are beautiful and clean, while others are rotting hulks. Why? Researchers in the field of crime and urban decay discovered a fascinating trigger mechanism, one that very quickly turns a clean, intact, inhabited building into a smashed and abandoned derelict
A Broken window
One broken window, left unrepaired for any substantial length of time, instills in the inhabitants of the building a sense of abandonment — a sense that the powers that be don’t care about the building. So another window gets broken…
So what do you do the next time you see a seemingly harmless line of code or bad design:
Don’t leave “broken windows” (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. Perhaps you can comment out the offending code, or display a “Not Implemented” message, or substitute dummy data instead. Take some action to prevent further damage and to show that you’re on top of the situation.
