Software decays. Unlike the general belief that code doesn't just "rot away", which makes sense, but software has its own type of decay, known as "software entropy" or "software rot".
Software entropy is the process of gradually decreasing the quality of source code until developers can't contribute to it any more. Code becomes obsolete and difficult to maintain, just like anything else.
This happens due to a number of contributing factors mostly related to the psychology and culture of the developers working on the project.
Question remains; how does it decay and how can we prevent it?
To understand how software rots we need to take a look at the Broken Windows theorem. The Broken Windows theorem is a theorem in crime science which states that crime is the result of disorder found in human societies.
Given a car left on a street for weeks, passers-bys won't care about it. It'll remain as is. Until a window is broken. In the original experiment, they left a car on a street untouched for weeks. But when they broke a window, the car was dismantled in hours.
By the same rule, a broken window in a building left unfixed will be followed with general disorder. Which is why NYC started cracking down on the tiniest things, in order to prevent broken windows.
According to a 2001 study of crime trends in New York City by Kelling and William Sousa, rates of both petty and serious crime fell significantly after the aforementioned policies were implemented. Furthermore, crime continued to decline for the following ten years. Such declines suggested that policies based on the Broken Windows Theory were effective.
Wrong management decisions that developers have to live with, bad designs, or poor code are all examples of broken windows.
Delaying fixing these broken windows to later times will only contribute more to software entropy. We all know that there won't 'another time' or 'later' because you'll be all too busy with new features or critical bugs that will leave even more broken windows.
Failing to fix those windows as soon as possible will leave you in the mentality that "all code is trash, I'll just get this over with". This mentality will greatly accelerate the entropy.
Given all of this, one must simply avoid breaking windows. If you want your codebase to last then you must fix all windows as soon as they're found. Introduce the concept of refactoring to your boss. Temporarily disable features. Label others as "unstable".
Do not leave a broken window in your production code. This will keep the mentality of care and attention to detail among the developers working on the code, and will eventually lead to easier feature addition, maintenance, and testing.
You don’t want to be the first one to make a mess.
— The Pragmatic Programmer
If you liked this article don't forget to love this post! If you found any issues with this article or have questions don't hesitate to comment them! Thanks for reading! You can follow me on Twitter, or read more of my content here or on my personal blog!