I believe that a codebase has entropy. I don’t think that I am alone in my beliefs.
A codebase with high entropy will most likely manifest code rot and brittleness.
Other people like to think in terms of technical debt.
For me, the concept of technical debt is a nice way of explaining to management that while we increase the entropy for the sake of a timely release, we will have to take steps towards decreasing it in the future.
Unlike financial debt, technical debt is not well defined. It has interest, but it varies wildly and is massively dependent on the people who try to manage it.
Entropy (and technical debt) is decreased by refactoring.
Don’t confuse entropy with complexity, they are different. Entropy is just the amount of chaos in your codebase. You can have nice, clean and complex code with low entropy.
For example: Increasing entropy to fit in a last minute feature that some important client wants, will take some amount of effort. The effort to decrease the entropy to normal levels will be dependent on the total amount of entropy in the system, the people that take part in the refactoring and the amount of time since the entropy was increased.
Let me explain.
Every codebase contains some entropy.
The higher the entropy the weirder and harder to refactor your code gets.
I think you can actually measure the total entropy in a codebase. Do it like this:
- Listen to your developers while they code.
- Count the number of swear words they use.
- Weigh the counts according to the developer’s age in the company*.
- Sum all the counts and divide by time.
I like to think of this measure as WTFs / hour.
Yeah, this is not an objective measurement and you can’t put it in your powerpoint or talk to your manager about it. But it’s fun!
* Older developers are more important because they are used to the code. If they are surprised by something, you can bet that it’s really ugly.
Some people are better at adding entropy than they are at removing it.
Did you ever write some sloppy code while thinking that you’ll refactor it later? Did you ever forget to refactor it and some co worker comes in and refractors it for you? Is that code now worse instead of better? That’s the guy I’m talking about.
Some developers don’t take the time to understand the code that they are working with. They don’t think about the bigger picture and what the code is trying to do. All they care about is getting it to do what they want.
Private method that looks like what I need? No problem! I’ll make it public without understanding the class it’s in.
This one is pretty straightforward.
The longer you wait to fix some bit of code, the longer it will take you to relearn what it does and how to fix it.
Keep your code entropy as low as possible from the start. This way you will have more stable releases, fewer bugs and you can add new features faster and cheaper.
Did you ever look at some software and learn that it has an unexpectedly large number of people maintaining it? Yup, entropy is to blame.
There is no silver bullet. Just use common sense and refactor regularly.
Oh and test your code too. Refactoring is scary without tests.