12 ms·

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 wi

by casion 6y ago

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.

joncampbelldev 6y ago
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?
- alisonkisk 6y ago
  "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.
  - joncampbelldev 6y ago
    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?
paulintrognon 6y ago
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).
- cyphar 6y ago
  In fairness, if the land had been left alone there wouldn't have been any invasive species.

by casion 6y ago

joncampbelldev 6y ago

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?

alisonkisk 6y ago
"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.
- joncampbelldev 6y ago
  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?

paulintrognon 6y ago

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).

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