The Boy Scout Rule

This is the third instalment in a series of articles about six core principles that my team, a software development team, and I compiled in order to develop a framework for decision making. The reason for building the framework was to build a common understanding of how we want to work. Writing it down allowed us to easily transfer that knowledge to new colleagues and to spread the word.

In this article I want to reflect a simple and yet powerfull principle introduced to software engineering by Robert C. Martin (Uncle Bob): The Boy Scout Rule.

Summary

The Boy Scout Rule by Robert C. Martin (Uncle Bob) advices software engineers to always leave the code behind in a better state than you found it. This habit of constant refactoring helps you keep your (software) solution healthy. Compromising on quality all too easily lead to an effect known as „The Broken Windows Theory“ that leads to a downward spiral of deterioration. Fostering a culture that values quality and good craftsmanship can quickly become an attracting factor for good engineers and thus an important competitive advantage.

The Situation

All too often you find people not taking the time to adapt software code to new requirements and instead working around limitations with workarounds. Consciously or unconsciously they thereby compromise quality. Soon you start noticing that the rate of WTFs per minute increases. People become frustrated and don’t want to deal with old code. They prefer starting things from scratch. Old software is quickly considered legacy, becomes second class and very rapidly the quality starts deteriorating.

Challenges

Workarounds

I have seen many cases where engineers started building workarounds in cases where they had to deal with problems in parts of a system that they didn’t develop themselves. Instead of fixing the problem where it originates, they start implementing workarounds in the parts of the system that they’re currently developing. Those workarounds make the system more complex and thus harder to understand and maintain. Because the root cause of the problem remains, it’s very likely that a similar workaround will have to be implemented elsewhere. This opens the floodgate for inconsistencies.

Bad Mood

In general, engineers have high expectations of themselves. They want to write Clean Code. Not being able work with and create clean code leeds to a high rate of WTFs per minute, which is a symptom for stress and discouragement.

The Broken Windows Theory

The Broken Windows Theory applied to software development implies that people will more likely write bad code in an environment with bad code. Put simply this means, that bad code will lead to more bad code. A serious downward spiral that ends in rotten software.

Solution

Refactoring

Refactoring is an often underestimated and misunderstood topic. However, if applied correctly it can be a very powerfull technique to ensure that you remain agile, competitive and up to date. One of my favourite articles on the matter explains the topic in a very visual and easy to understand manner: Refactoring — Not on the Backlog! by Ron Jeffries. Another renown expert on the topic of refactoring is Martin Fowler. I highly recommend reading the following two articles on refactoring:

• Workflows of Refactoring by Martin Fowler
• Opportunistic Refactoring by Martin Fowler

If you took the time to read those articles you might have noticed the term „technical debt“ popping up again and again. You may want to read this article to better understand the analogy of „technical debt“:

• Technical debt 101 by Maiz Lulkin

Praise

Appreciation is an easy and very cost effective method to encourage and motivate people to write clean code and to refactor. Praise in the form of

Thank you Alice for taking the time to refactor that library, it’s so easy to extend now.

or

Hey Bob, that code you wrote for the new RESTful API looks really neat, respect!

is extremely powerfull and creates a culture that values good craftsmanship.

Pair Programming and Peer Reviews

If I learned one thing during my professional career, it’s that people work both more effectively and more efficiently in teams. Working in teams allows people to easily learn from each other, to get instant feedback from their peers and to address and resolve personal insecurities. Pair programming or peer reviews are powerfull techniques that harnesses the full potential of a team.

Results

Efficiency

Keeping your code clean through constant refactoring ensures the fitness of your code base. With a few simple habits you can make sure that your solution stays fit and that you stay very agile. It’s like a kitchen that you always clean up right after using. It’s always ready to be used, even if some friends drop in spontaneously you can instantly offer them and prepare a dinner. If, on the other hand, you wait with the cleanup and let the dishes pile up, when your friends drop in unannounced, you will have to clean the kitchen before being able to prepare a dinner. This will cost you time and even discourage your friends to stay.

Motivation

Being able to work with clean code is a huge motivator for both your team and potential new hires. Good and healthy environments attract good and healthy behaviour. In an industry in wich skilled people are scarce, this can quickly become a competitive advantage.

Conclusion

Keeping your environment and solutions clean and fit through constant care can be achieved with a few simple habits. A key element to this is refactoring, through which you constantly adapt your solution to current requirements. By showing appreciation for those who make an effort to write clean code, you can foster a culture that values good craftsmanship. This being a huge motivator for your team and an attracting factor for new hires.

I’m very eager to hear your opinions and experiences, please write a comment.

Thank you Raffael Schmid for writing the initial version of this article.

From Dev-Team with ❤