Matt from LinkedIn roasted the Boy Scout Rule. I had to correct him, because what he is saying is just wrong.

He wrote:

“Leave the codebase better than you found it” is potentially BAD advice!

Some developers think that when they touch some part of the code, that is the time to do other refactoring to it.

It probably isn’t.

You dramatically increase the likelihood of breaking that code and causing new problems.

The code is likely good enough, even if you don’t think it is “perfect.”

You end up with scope creep because now you also think you need to add unit tests, upgrade this, document that, etc etc etc.

Avoid the scope creep trap. 🚩

Your refactoring may make the code more complex and actually harder to support.

Most importantly, it is time you could have spent building something else that provides value to the users.

In summary, modifying code that already works isn’t the worth the risk and there are likely other tasks you could do to deliver actual value to the users.

If ain’t broke, don’t break it.

My response#

Gosh, you’ve oversimplified the whole thing by thinking short-sightedly. It’s generally good advice, but like any practice, it can be applied badly, in the wrong places, by inexperienced people, in code without testing, in a product that’s only maintained with no plans for new development, etc.

If you’re worried that refactoring will increase the risk of bugs or scope creep, you’re either hiring the wrong people or not helping them learn how to code properly.

Nathan said it needs to be intentional, so I added#

Of course, this should be intentional. I would also add that refactoring should be in line with the business strategy. If something works but rarely changes, or if we don’t see any business or technical value in not rewriting a piece of software, then it doesn’t make sense.

But on the other hand, if we see that certain changes will improve our development speed, security, performance, help us update dependencies (again, security), or we have discovered that our software model is not flexible and changing it will allow us to deliver future features faster, solve future business problems, then the principle of leaving the code in a better state than we found it makes perfect sense.

I’m not talking about a revolution. Rather, I’m talking about making changes to the code as we achieve a goal, especially if we know we’re going to be making a lot of changes in the future.