You need to fix your problems fast and adequately — the Broken Window Theory.
As developers, we know how often we feel resistance to doing things the right way. Especially when we are under stress or have deadlines, don’t mistake shortcutting things when a good solution should be implemented.
I did that in the past and learned the hard way from it.
And I think I am not alone, right?
Please let me know what your experiences are :)
What is this theory about?
In short, It’s a criminology theory from 1982 which describes the resulting decay of, for example, buildings if society starts to not care about them anymore. For example, once a window of a building breaks and does not get fixed, it’s more likely that another one will break soon. Grafitti will follow, which is the beginning of the decay.
The same will happen to your project, product, or codebase as soon as you stop to take care of it. Taking care means addressing problems straight and direct, not telling yourself you can do that someday later.
Let me explain why.
Engage problems when they occur
We work in an environment of pressure; everything needs to get ready to ship, and features quickly become overdue, leading to even more stress. When developers encounter problems in their codebase during a stress phase, it can likely happen that the developer will fix the problem with a shortcut instead of a solution.
An example can be fixing complex typing errors by adding ignore comments. If we are lucky, a TODO comment promises a fix someday later, so we have the chance to search for these shortcuts later on, which isn’t a good practice at all.
However, in reality, the future fix has a low chance of really being implemented in the next future. The reason is simple; the environment won’t likely change tomorrow, so why should the problem be fixed on another day under the same circumstances?
It’s essential to fix a problem with a real solution when it occurs to ensure the team is staying on top of its game. It will take more time initially, but it will save time and money later on, for sure.
The environment won’t likely change tomorrow, so why should the problem be fixed on another day under the same circumstances?
A broken window is similar to a shortcut fix.
A shortcut fix can be various, starting with lousy-any typing, no planning, no testing, or ignoring a definition of done before you commit changes to the repository.
Once the team members realize that it’s okay to work in that manner, it will continue to worsen. Suddenly your codebase is full of unfinished features, ignorings, or shortcuts, which will eventually lead to a broken state of the product that isn’t reversible anymore. Just because the mental barrier is too low prevents people from working towards quality. It all roots back to natural human behavior and is a solely cultural problem.
The solution is to stay on top of your game.
Fixing problems as soon as they appear with an adequate solution should be part of your company culture. The last article discussed mindset, culture, and maturity, which are directly correlated.
Fixing problems as soon as they appear with an adequate solution should be part of your company culture
If it’s part of common sense to fix problems the right way, everyone in the team will try to hold up to that behavior. However, you should be willing to meet the requirements and quality levels; for this, a cultural foundation like this is necessary.
