You are in front of that class and you start sweating. A switch which is not needed, unused legacy code, several blocks of code repeated, a condition based on a variable which never changes the value… and other things that usually appear in your worst nightmares. Probably sound familiar to you?
I’ve been in this situation recently. The code was not only mine, but even it was from a different project I’m working in. I’m collaborating with another project and I got to add some new improvements and features to an already existing one.
And I was there, in front of my computer thinking “Oh, boy, this is a mess. I don’t know where to start from”. “Should I refactor this code? Made it more readable and maintainable?”, I wondered. This is not even my project. How is the team responsible for this code going to take if I change completely the code?
And then I remembered the Boy Scout rule.
Apparently (and I say apparently because I’ve never been one), Boy Scouts have one rule which is that every time they go camping or in a group trip they need to leave the place tidier and cleaner than they encountered it (something not so difficult seeing how disrespectful and dirty people are)
And so for the code. For us developers, the Boy Scout rule means that you must leave the code you better than you found it. Probably a bit cleaner, probably with more tests, probably with better naming,…
Bad code sometimes is inevitable. We code a pretty decent first version of the code but then it comes issues fixed, patches, new features not considered in the first design, different developers with different styles,… and that decent code someone implemented in the first version becomes something difficult to read and maintain… and you wanna cry.
When it’s too late we need to allocate some time of the project to remove some Technical Debt. That’s when the Product Owner is not happy, and the Business Manager is not happy, and… only developers are happy. Because technical debt doesn’t add direct value to the product.
That’s when it comes the Boy Scout rule. If we apply it every time we have to add new code to an already existing one we contribute to a better and cleaner code. Probably to allocate less time in technical debt, and most probably to happier Product Owners.
If everyone is happier and the code is more maintainable and readable, why not apply it more often?
By the way, I refactored the code and the other team thanked me for improving it. They knew this code needed a huge refactor.
Top comments (1)
This is a great rule, especially when you apply it every day.
It helps you to prevent big refactorings that otherwise would be needed on a regular basis.