Entropy
/ˈɛntrəpi/: lack of order or predictability; gradual decline into disorder.
Entropy in physics refers to the amount of “disorder” in a system. The laws of thermodynamics guarantee that the entropy in the universe tends toward a maximum.
While the laws of physics don’t apply to software, entropy hits it hard. When disorder increases in software, programmers call it “software rot.”
The Broken Window Theory
Software rot starts with one broken window.
One broken window, if left unrepaired for a substantial amount of time, instils a sense of abandonment. So another window gets broken. People start littering. Graffiti appears. Serious structural damage begins. In a relatively short time, the building becomes damaged beyond the owner’s desire to fix it, and the sense of abandonment becomes reality.
The Boy Scout Rule
There are times when I have hacked together code because the entire component was somewhat hack-y. This only made the code worse than what it already was and made it tremendously difficult to change it later. In contrast, if you are working on a team/project where the code is cleanly written, well designed, and elegant — you will likely take extra care not to mess it up.
Don’t leave “broken windows” unrepaired. Fix each one as soon as it is discovered. Leave the code cleaner than you found it.
Dealing With Entropy
As Uncle Bob says, it’s not enough to write code well, the code has to be kept clean over time. If we all checked-in our code a little cleaner than when we checked it out, the code simply could not rot. The cleanup doesn’t have to be something big. Change one variable name for the better, break up one function that’s a little too large, eliminate one small bit of duplication, clean up one composite if statement.
Done And Gets Things Smart
Programmers are all smart and get things done but we should cultivate the habit of getting things done and making code smart.
“You want someone who, when you give them a project to research, will come in on Monday and say: “I’m Done, and by the way I improved the existing infrastructure while I was at it.” — Stevey’s Blog Rants
TL;DR
You see evil and you destroy it. Always be refactoring. I’ve found that the following prioritization helps quite a lot:
bugs > refactoring > features
This applies to any programming paradigm, not just OOP. Andy Hunt and Dave Thomas have written about this extensively in their book The Pragmatic Programmer.
Be sure to check it out and tell me your views.
Originally posted here.
I completely agree with you, I have been working on code base, which was littered with sql prepared statements with the java code. But if i try to extract the statement and convert it into java callable statement, i have to get the permission of business and they start to worry whether it will break the code. Sometimes the developers get the reply it is already working, business doesn't need the developer to work on it. I can rant so much, but i think the developer need to have some freedom to refactor the code :-)
Have the business people got burnt in the past by devs trying to clean the code? Do you have automated tests in place that make sure if you refactor the code that you can show it still functions in the same way?
The best way to handle this is in the course of normal feature work when you have to touch the code, that is when you clean it. So then you can just roll the change in with normal feature work and do not need to ask for the time to clean the code.
TDD can give you the freedom to clean the code and put everyone at ease.
I'm a bit leary about generalizations like this. The sentiment is in the right place, but often it can be misapplied. The biggest problem is understanding what "cleaner" code actually is. There is a wide range of opinions on this. If a change is trival, why is it made at all. If it is non-trivial, then the worry about a functional change is real.
I think cleaning for the sake of cleaning is wrong. There should be a very clear goal anytime you go to refactor something.
I see this "no cleaning for the sake of cleaning" line a lot in contribution guidelines. But what about small changes like improving variable names, improving formatting etc? Should they only be done when you're changing the functionality of that particular piece of code then?
Yes, changes are best made when adding functionality or fixing a defect. Preferably prior to the fix/addition. I feel as though there needs to be something motivating the change, otherwise you might spend forever cleaning the code. The reason I'm cleaning the code is because the messiness is getting in the way of a new feature, or is the likely cause of a defect.
It's important to consider the rest of my approach though. I spend a lot of time "cleanign" prior to implementing a new feature. Essentially I try to refactor so that the new feature will be an easy addition, rather than having to hack into the existing code.
With defects, I prefer fixing underlying problems than surface issues. Cleaning code is often just the best approach here.
Nice article. I posted a similar one a few years ago entitled Are you a Boy Scout?. I think this practice is important for any dev at any level. It shows your passion for code and if you have code reviews, a great way to transfer knowledge - ultimately creating a positive feedback loop. Just be mindful not to Boy Scout everything!
As a beginner, this rings very true. The more code I add, the more errors I encounter. It even renders working code useless when I remove the broken code. This is going to be a very difficult, and rocky learning process. I know that my faults lie in ignorance, and just having very little experience with the code I am working on. I do my best to keep the code as clean as possible for error checking, and to avoid any future issues. Maintaining order is key.
Not a bad article/idea…but you know the Broken Windows theory has been disproven and shown to be hella racist, right? Not the best analogy to use here, particularly since you have other analogies to lean on…