Don't Break a Window, Break a Leg.

Back in 1999, andrew hunt and davic thomas gave us their software engineering quiddity in the form of a book, and after 20 years they updated it and added even more gists to the mix in the second edition of the infamous "The Pragmatic Programmer".

one of the best topics in the book is The Software Entropy topic, which I wanted to share my thoughts on it with you cause why not !

What is Entropy ?

💡 in physics, Entropy is a thermodynamic quantity representing the unavailability of a system's thermal energy for conversion into mechanical work, often interpreted as the degree of disorder or randomness in the system.

"the second law of thermodynamics says that entropy always increases with time" · "the sum of the entropies of all the bodies taking part in the process"

so entropy represents the amount of disorder in a system, what does that have to do with software?

Technical Debt

our authors states that software is immune to all physical laws, except for Entropy. when disorder increases in software, we call this Software Rot, while other more optimistic folks use the term technical debt. with the implication that they might pay it back, when they probably won’t.

what ever the name, this is an uncontrollable issue that spreads across the code base and causes major setbacks.

what is technical debt?

so our friend Kemo is a feature owner in some software project, he has his feature defined but not very well, so as every team leader he delegates some of the tasks, or issues, to his team mates, and because the feature is not well defined, some corner cases are not handled probably and due to time and delivery constraints some corners were cut to deliver the feature on time, this resulted in a lot of issues reported on the GitHub repo with the premise that it’ll be fixed as soon as the feature is delivered.

but here comes the catch, the feature request, that is ill defined, has changed, mods were requested, and the old issues were abandoned for new issues. here Kimo decides to focus on the new requests and leave the old issues in-place with out fixing or modifications.

until the stack-holders decide to scale the feature even more, but the debt becomes too high that it out weights the benefits of scaling, the feature’s old code base is abandoned, a refactoring phase starts and everyone is cursing everyone now.

in brief, Technical debt is a term used in software development to describe the implied cost of future reworking required when choosing an easy but limited solution instead of a better approach that could take more time

What's up with Broken Windows?

so our authors gave us a great example of the bad code as the broken windows in an urban area, as most of the fire comes from the smallest spark

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. People start littering. Graffiti appears. Serious structural damage begins. In a relatively short span of time, the building becomes damaged beyond the owner’s desire to fix it, and the sense of abandonment becomes reality

What do we take out of that?

as the authors said,

“don’t leave “broken windows” (bad designs, wrong decisions, or poor code) un-repaired”

just keep things clean and tidy, and if you find things already clean and tidy, just don’t be the one inflecting damage due to deadline, release date, or any other crisis of any sorts, don’t be the first one to make a mess and add up additional damage.

just tell yourself, “No broken windows”

Image by Peter H from Pixabay