Software Design: Entropy
What is Entropy?
The term was first introduced in Thermodynamics, as a quantitative measure representing the unavailability of a system’s thermal energy for conversion into mechanical work. In a broader sense, it is interpreted as the degree of disorder or randomness in the system.
The laws of Thermodynamics guarantee that the entropy in the universe tends towards a maximum. (Read more)
Software Entropy
Although originating from physics, entropy has its place in software development as well.
Whether it be work or your own project, you will come across disorder to some extent in your software systems. When disorder increases in software, we refer to it as “Software Rot” or a more common term — “Technical Debt”.
To avoid entropy in our software systems we need to understand where it all stems from, let’s take a look at a real world example to better illustrate this problem.
Broken Windows
Broken Windows is a popular criminological theory stating that visible signs of crime and civil disorder create an environment that encourages further crime and disorder… and so on.
In a field study run by a psychologist from Stanford University, two cars were abandoned and parked on the street with their license plates removed for a week. For a week both cars went untouched.
At the start of the next week, the researcher smashed in a single window on one car. Before the end of the day the car was stripped for parts, more windows smashed, graffiti on the sides of the car — it was destroyed.
The psychologist concluded that there was a trigger mechanism, “a broken window”.
Similarly this concept can be applied to buildings, entire neighbourhoods and so on. The sense of abandonment and hopelessness that comes from ignoring a clearly broken situation often sends the message that it can’t be fixed, nobody cares or that the situation is doomed.
These negative thoughts spread amongst everyone that passed the damaged car leading to further vandalism and damage.
Broken Windows in Software
In software, clean systems deteriorate faster once there is a broken window. Our goal is to avoid living with broken windows. Contributing factors often come from the psychology or culture at work, or on a specific project.
Even with the best development team, a single broken window will set precedence for the quality of code that is shipped in the future. It’s all too easy to slip into the mindset that “The codebase is crap so I will also ship subpar code”. If you keep thinking that nobody has the time to go around cleaning up all the broken glass of a project then you’re letting entropy win.
Neglect accelerates software rot more than anything else
Since this disorder can spread uncontrollably as we’ve learned from our fellow physicists, how do we fight it?
Preventing Broken Windows
Just as working with a crappy codebase pushes you to ship even crappier code, the same psychology applies to codebases that are pristinely written, well designed and elegantly maintained. You are inclined to take extra care not to mess it up — you don’t want to be the first one to make a mess.
One broken window is one too many — The Pragmatic Programmer
There is no such thing as perfect software, so we can’t expect not to run into a broken window every now and then. Bad designs, wrong decisions and poor code can all lead to broken windows. These should be fixed right away, don’t leave a broken window, broken.
Even in high pressure situations where time is of the essence, board up the broken window and have a plan in place to repair it as soon as possible.
I hope you found some worthwhile information while reading through this post. If you want to apply some of these lessons in your projects, I’ve listed some suggestions below. Heres to building better systems! 🍻
Suggestions
Help strengthen your team by surveying the project “neighbourhood”. Choose a few broken windows, discuss with your team how you will fix them and begin repairing the windows.
Make this a recurring event — mechanisms work, good intentions do not.
Ask yourself and your team the following questions when a broken window is identified…
- Can you tell when it was first broken?
- What’s your teams reaction to a broken window?
- What was this broken window a result of?
- What can you do about this broken window?
Thank you for reading! If you liked this article and want to learn more about software design subscribe to my email list and give me a follow! Become a member to support the community of writers on Medium.
