If you're a developer and you don't see the connection between a bunch of merry men making campfires 🔥 and your job, then you're in the right place! The Scout Rule (formerly Boy Scout Rule) established by Robert C.Martin ("Clean Code") is about a fundamental development principle that allows continuous improvement of an application's code 📈. Once this concept is understood and mastered, see it as an additional asset in your job, which will allow you to have a guideline when you are in the process of developing a new feature.

The Scouts' action we need to learn from

One Scout rule is that the place where they set up camp overnight should be cleaner when they leave than when they arrive. The first thing to do before camping is not to damage the place where you will spend the night. Once the camp is set up and all the work is done, the Scouts go to bed. When they wake up the next day, before setting off again, they remove their equipment and clean the camp. This action, carried out with a certain respect for the environment that welcomed them, even ensures that the place will be cleaner the next time they set up camp there.

What does this have to do with the development of my US?

It can all be summed up in one sentence, very close to the concept we just mentioned:

Leave the code in a better state than you found it.

The goal, when developing a feature, should not be only to get the task to DONE ✅ as quickly as possible. During the development phase, our attention is going to be focused on certain portions of the code, in which we will certainly spot some inconsistencies, potential bugs or anomalies. When these are simple and quick to fix, the Scout Rule states that this is the right time to do so. Fixing these errors will allow you to continuously improve your code and gradually reduce the technical debt.

If this is done continuously, you will always be able to focus on the important and interesting features of your application, because the problems will never accumulate within it. This avoids, in the long run, having to focus on uninteresting and sometimes aberrant technical tasks, which do not bring any value to your customer but only exist to reduce the technical debt and prevent your application from collapsing. This is a far cry from writing beautiful, simple and maintainable code.

When to stop?

You should not go to the extreme of refactoring ⚠️. If the application of the Scout Rule takes too much time and energy or leads to the modification of too large a part of the code than initially planned, it becomes another task that must be qualified and quantified. Indeed, the goal is not to create another task, but rather to continuously improve the portions of code you are working on. Modifying parts of the code that were not part of the original task or attacking structural functions out of perfectionism are not part of the Scout Rule.