The Boy Scout Rule in Coding
Leave it better than you found it
Keeping your code maintainable and easy to read is an incredible challenge. Can you rise to that challenge, and even maintain the Boy scout rule?
The scout’s rule
Robert Baden-Powell is attributed with the following quote
Try and leave this world a little better than you found it, and when your turn comes to die, you can die happy in feeling that at any rate, you have not wasted your time but have done your best.
This has been interpreted when scouts camp with the following:
Always leave the campground cleaner than you found it
Which is nice isn’t it?
When the scouts camp somewhere, it doesn’t matter who dropped some litter on the floor — even if it was someone who isn’t in the scout troop.
The effect of a rule like this is manyfold, but one result of this is that the scouts get a good reputation wherever they go. They are seen as some sort of force for good, and have a rule that is simply to conform to.
They even make it fun to follow the rules (have a pitch-check at the end of the camp).
Uncle Bob’s interpretation
Uncle Bob (Robert C. Martin) has further interpreted the quote as:
Always leave the code you’re editing a little better than you found it
Indeed, the act of leaving a mess in the code should be as socially unacceptable as littering. It should be something that just isn’t done.
As software is developed and evolves over time technical debt is said to increase. Members of staff change, and yet the code stays the same and features are added onto the code.
Keeping code in good condition and clean makes sense, and code should represent your understanding of the code at any given time.
Writing good code
Code should be written in such a way that it is clean and easy to understand. Programmers then build features on the code, representing their understanding of the code and the features programmed at any given time. Software developed with several modules may take 3 days of effort to write a particular feature. However, as time goes on more and more features are added to the modules that may necessitate a new module.
The challenge is that if the new module is not created a comparable feature will take 5 days of effort to write due to the increasing complexity of the code base.
This extra time is known as technical debt and represents a metaphor where it is recognised that layering feature on feature without updating the codebase leads to a debt of sorts that needs to be paid back.
Good code should represent your understanding of the working of the software at any given time
This concept of technical debt underlies the idea that code which is a mess, or poorly written code is even worse. If you are writing code that you don’t understand this is the first thing that needs to be fixed in your development of software.
Even if you find code that is a mess which you didn’t create, there is a moral impetus on you to create software that is easy to understand, clean and maintainable going forwards into the future.
Developers are often excited when they move onto new features and new ways of exploiting software solutions to a problem. By making the members of your team good citizens you move towards a future where developers work to create software that is always a little better, either in code or general quality than when they found it would be an ideal situation.
Programmers working together, working together.
This is a situation that you’d want (right).
If you’ve any questions, comments or suggestions please hit me up on Twitter