Make it work, Make it right and make it better.
What is the broken window theory and how is it relevant to software development?
“When you are working on a problem, you sometimes get so close to it that you can’t see all the options. You miss elegant solutions because the creative part of your mind is suppressed by the intensity of your focus. Sometimes the best way to solve a problem is to go home, eat dinner, watch TV, go to bed, and then wake up the next morning and take a shower.” — Robert C. Martin
In the late 1960s, there was a field study, conducted by a Stanford University psychologist named Philip Zimbardo. He abandoned a car without a license plate in a poor, crime-ridden section of New York City. After a few minutes, the radiator and battery of the car were removed. Soon after, other valuable parts were too removed. In the next 24 hours, the car windows were smashed, parts were stripped and destroyed completely.
He abandoned another car without a license plate in a wealthy neighbourhood of Palo Alto, California. The car remained untouched for more than a week. Then he took a sledgehammer and smashed part of the car. Within a few hours, passersby quickly ripped the car apart, Windows were smashed and the car was utterly destroyed.
Based on this study, he concluded that, if something is neglected for a long time then, no matter how rich or poor a neighbourhood, it can quickly become a target for vandals.
After 30 years, the criminologists George L. Kelling and James Q. Wilson were fascinated by this field study and wrote an article about it.
https://www.theatlantic.com/ideastour/archive/windows.html
“The idea [is] that once disorder begins, it doesn’t matter what the neighborhood is, things can begin to get out of control,” — George L. Kelling
“Human behavior is profoundly affected by its environment — [Broken windows] are a declaration that the environment is uncontrolled and uncontrollable” — James Q. Wilson
This study also became the base for “The broken window theory”, which eventually led to the controversial “stop-question-and-frisk” program and “civic cleanup” in New York City in the 1990s by Rudy Guiliani, the former mayor of New York.
What is broken window theory?
If a building has a broken window that is not repaired for a long period, then it sends the message that no one cares. If this window is not fixed, passersby will conclude that the owner does not care or doesn’t care much for it. They may eventually break other windows in the house and kick out the residents.
On the other side, fixing broken windows as early as possible sends a signal that the system is monitored. Hence no criminal activity is allowed.
Broken window theory in software development
The broken window theory applies to many areas in real life including software development. Let's see how it is applicable in software development.
If a developer sees a code that does not follow any coding standards, has too many typos, bad naming conventions or inconsistent code styling then that person is more likely to continue following the same approach regardless of how good a developer the person is. That is to add more crap code to the crappy system.
This kind of poorly maintained system clearly communicates to anyone including new developers that no one cares about the system. This will eventually lead to a situation where no one wants to work in the system anymore.
One broken window — a badly designed piece of code, a poor management
decision that the team must live with for the duration of the project — is all it
takes to start the decline. If you find yourself working on a project with quite
a few broken windows, it’s all too easy to slip into the mindset of “All the rest of this code is crap, I’ll just follow suit.” It doesn’t matter if the project has
been fine up to this point.— The Pragmatic Programmer by Dave Thomas and Andy Hunt
How to prevent broken windows?
Broken windows create uncertainty in a project. A disciplined team overcomes the obstacles and builds a predictable environment by controlling the level of uncertainty within a project. To build an environment that is predictable, multiple factors must be taken into consideration, including how every developer codes.
Developers spend too much time looking for the perfect solution. However, it’s extremely difficult to get it right the first time, and this may lead to analysis paralysis. Kent Beck, the creator of extreme programming, suggests a simple, disciplined and pragmatic three-step incremental development approach to avoid this.
“Make it work, make it right, make it fast.” — Kent Beck
Following these steps help the developer remain focused on getting the work done and avoid falling into the trap of premature optimization.
Step-1: Overthinking kills productivity. Just start coding and make it work
If you are working on implementing a new feature or solving a problem in your application, you might not have the complete solution at first and are still exploring possibilities. If you are looking for the perfect solution at this point, then you end up spending too much time thinking and examining different options since there are many uncertainties.
Instead of exploring too much, just start coding and don’t worry about coding standards, naming conventions, comments, duplicate codes, unit testing, etc. The goal here is to get a working solution as quickly as possible. Remember that the code may be ugly as hell and should never be pushed into a production environment or even the source code repository.
Stopping at this stage will leave too many broken windows. So don’t.
Step-2: It's not about just making it work, it’s all about making it right
Now you got the working solution. The next step is to ensure that, the solution is maintainable and production-ready. This is where you follow the software principles and perform all the necessary refactoring.
In this stage, you can change the code with proper naming conventions, apply design patterns, add enough unit tests, perform code cleanup and optimizations. Ensure that, the code is better and maintainable in such a way that anyone can understand it with less effort.
At this stage, the desired solution must be production-ready and fully presentable to the user.
Step-3: Occasionally, being right isn’t enough. Don’t be afraid to be fast and better.
The last stage is to make things better/faster. This is an optional one. But there is always room for improvement. Most of the time, we don’t get the time or resources to perform this step. But if there are resources and time, this is when we improve the code/solution.
Be extra careful in this step as you may over-optimize the code and end up with code that is hard to read. Most of the time, the software don’t need extra optimization or performance improvement. In such cases, just stop at the previous stage.
“The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.”
— Donald Knuth.
Pro tip: Treat warnings as errors
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.— The Pragmatic Programmer by Dave Thomas and Andy Hunt
“You are responsible for the quality of your code. Not your client. Not your boss. […] You don’t go to the doctor and say: You know what doc? I’m in a hurry, why won’t you skip washing your hands?” — Michael Toppa
References
https://www.britannica.com/topic/broken-windows-theory
https://blog.codinghorror.com/the-broken-window-theory/
https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast
If you liked this article, you may check my other articles too.
Further Reading
More content at PlainEnglish.io. Sign up for our free weekly newsletter. Follow us on Twitter, LinkedIn, YouTube, and Discord. Interested in Growth Hacking? Check out Circuit.
