As the cost in time and effort of refactoring goes up, developers will add more bad code because it’s easier and quicker. The result is the bad code in a project is like a snowball being rolled in snow, it just gets bigger and bigger – Hosk
I was reading an article which had the concept of the boy scout rule boy scout rule, it’s from the pragmatic craftsman and I would recommend the excellent book The Pragmatic Programmer
If you haven’t read it yet, I recommend you, it will help anyone who has to write any code or is doing any development.
Development and the boy scout rule
Boy scouts have a rule
“Leave the campground cleaner than you found it.”
The other makes this point about code
“the code cleaner than we found it.”
What does this mean
The meaning of the quote with regards to code, is to encourage coders not to add bad code/quick fix code.
I would classify quick fix code as pushing and poking in some code to fix a problem, which adds to the complexity of the code rather than simplifies it. It might fix the problem but if the code is poorly written and structured it is moving the code towards spaghetti code
If you think about a teenager who keeps putting off cleaning their room by hiding dirty clothes under pillows, shuffling things in cupboards. If the teenager keeps doing this in the end the room turns into a big mess. This is ok until the teenager wants to find something, they can’t because stuff is everywhere, there is no order and it’s hard to work out where to look.
Instead of cleaning and tidying up the room, developers when adding bug fixes, keep placing quick fix statements, which over time slowly creates bigger and bigger methods, code complexity increases. The code because tightly coupled and starts to get more like spaghetti (e.g. code is linked together), maintaining, enhancing and debugging the code becomes difficult.
This is where the boy scout rule should come into play
“Leave the camp ground cleaner than you found it.”
If you adhere to the rule above it would mean instead of adding quick fix code, you add the code properly which may mean refactoring classes and methods and keeping the code. It will probably take longer in the short term but it will keep the code well structured, simple and readable (why code readability is important)
Code which isn’t readable (the code which gets the quick fixes) is
- Difficult to understand
- Longer to debug
- hard to maintain
- tricky to extend
The codes growing method/class size, increased coupling and added complexity results in the code taking more time and resources to maintain in the future.
When changing code you should focus on making it readable and adhering to good programming standards.
The benefits are
- Removes duplicate code
- Easy to understand
- Consistent
- Small methods which do one thing
- Logically structured and designed
What I don’t like about the boy scout rule
The idea is great but when trying to explain this concept to other developers. For developers/programmers to follow this rule it will result in them doing
- Refactoring code
- Writing better
- Keeping to high standards
- No quick bug fixes
- Increased time and effort to change code
- Increase in Testing
It’s the difference between quickly shoving some clothes in a draw and cleaning the whole room. Interestingly outside of coding I am very messy person
Acting like a boy scout and follow their rules and tenants is not initially appealing to most developers, particularly if it’s going to take extra time and effort.
My point is it can be hard to persuade other developers to put this amount of effort in, even if they will benefit and save time in the long term.
How do we sell the long term benefit over a short term gain
Help your future self
What I try and do is explain to developers is this will save themselves time and effort in the future and will make their job a lot easier in the future.
If you wrote the code now, there is a good chance you will pulled back into bug fix, maintain and enhance it later on. When you are working on a project full time, you have a great understanding of the project and you are in the project zone.
Being in the project zone means you understand the code AND all the business rules/business knowledge which goes with the project. Like sportsman being in the zone doesn’t last and you move onto other projects (although sometimes it doesn’t seem like that). Due to your extensive knowledge of the project, the business logic and the code you will be the prime candidate to fix any bugs which get raised.
The Messy Garden Shed
If you think of a project customizations like a garden shed. If every time you use the lawn mower, spades, bird feed, kids toys you tidely place all the items back. When you need to go into the garden shed a few weeks/months later you can easily find everything without having to remember where you last put things.
If you have a messy garden shed where everything is thrown into the shed and items are over and under each other. To find the item you want you would have to try and remember what you used last (you might not have been the last user). If you can’t remember you can slowly start pulling things out, looking around. With everything scattered around it’s difficult to know what’s in the shed, let alone where it might be.
It takes a lot longer to find things in the messy garden shed but if you went into the shed the day after you used the spade, you would have a good chance of knowing where you put it.
The messy garden needs you to remember where things are, this is similar to needing to understand the code and business logic in complex code solutions.
In six months plus time you won’t know the code and you definitely won’t remember the business rules and business logic.
So the code has to be as readable as possible and should not be complex
Scare them
You could try and scare the developers with this great quote
Why you can’t let standards drop
This is a great rule but I’m not sure how effective this would be at movitating people to tidy and refactor the code. Unless you hired a violent psychopath to walk around the office once a month and maybe do a few code reviews.
Developers should have enough respect in their work to do this as a matter of course or to help themselves out if they have to fix the code later.
Remember
Go round the officing saying this to fellow developers at least once a day
Times may change but standards must remain
Enjoy your work and take pride in creating excellent simple code because as soon as you stop doing it, so will everyone else
Hosk's Dynamic Blog 