Hacker News Reader

Comment by meowster | Hacker News Reader

Off topic, but the title reminds me of Scouts: Always leave a place cleaner than you found it.

I think it's a good philosophy, whether it's about code or trash. It makes everyone's life better overall.

Until you make a bunch of choices about "better" that are based on presumptions that are incorrect. Now you're just making things worse and filling yourself with a sense of accomplishment that puts you out of touch with reality.

When I was in scouts, our scout leader was adamant that we should leave the place "The way it would have been if left alone" and not try to push our own ideas of "better" on things. Which I think is a much better line of thinking, even if still flawed.

Whilst improvements shouldn't be done ad-hoc without consideration, I think the concept of "left alone" applies more easily to the concept of natural spaces. In code it is really stretching the metaphor to do much more than very basic tasks like renaming or code formatting (e.g. picking up trash). Adding a test doesn't feel like "left alone".

One of the examples in the article is upgrading a dependency. This could easily fall into the category you mention if the upgrade itself is not properly tested. A considered approach would be:

"I want to make a small improvement, oh I see this dependency is out of date and has some minor vulnerabilities or perf issues, or is missing a feature that could come in handy for XYZ. Hmm, there are no tests confirming our assumptions about the current library version, nor are then any tests are our code / systems that use it. I guess my improvement should be to add those tests, then next time someone has the same idea it'll be an easier upgrade"

I am unsure but I also interpret from your first sentence that you may have seen people use this rule as a defence for gold plating (the opposite of KISS or YAGNI). Similarly this should fall under the heading of changes made without proper discussion, thought or consideration.

Otherwise I think we're really stuck, if team members cannot be trusted to properly interpret the boy scout rule without messing up a codebase then how on earth can they be trusted to build the foundation of their company / team / system?

"left alone" corresponds to how it was designed. Your task is to push the code a little closer to the design, which always has compromises in implementation.

The big fights come in (as seen in comments in this post already) when there was no original design, and it's mess vs possibly dubious attempts to clean up the mess.

I think another possibility in addition to what you mentioned is that the original design was incorrect, or even just not very optimal. Just as an aside.

However this is all becoming a wide ranging statement about the entire job of a dev team. So far removed from the extremely innocuous advice of the article around "make small improvements regularly". Whilst you can apply caveats to that around "test your improvements", "check your improvement with others more familiar with that code" etc etc, these are all things that should be expected of a professional. At the risk of talking about no-true-scotsman.

If someone cannot be trusted with the advice "make small improvements regularly" then what the f* can they be trusted with?

The funny thing is, is leaving the land "the way it would have been if left alone" better? In many cases, it is debatable.

In New Zealand, there are many invasive species of animals and trees. Should they interfere and try to remove the invasive species? Or you should they "leave it alone" and let the pine trees take over all native plant species? (the same is happening in the french Alpes where pine trees are invading a lot of land).

In fairness, if the land had been left alone there wouldn't have been any invasive species.

That's why it's called "the boyscout rule" and the verb "to boyscout".

Eg in a PR description "I also boyscouted the entire login service a bit while I was in there".

Reply on news.ycombinator.com