The tyranny of best practices
Early on in my career my team was approached by one of our team leads. “We need you to, as a team, make a commitment to follow best practices.” Several members passionately and emphatically said “Of course!” instantly because what programmer wouldn't want to follow 'best practices', best practices are best after all. Before I responded either way, I asked “What best practices?”
There was no answer.
A reminder email came out “Please sign the agreement to stating you will follow best practices.” so I once again asked, this time also offering to help define what our best practices will be. Instead the response came back, that I should research our documentation and try and find if we have already defined best practices somewhere.
This isn't to say that Best Practices as a whole is bad. The problem arises in the blind allegiance and the dogmatic adherence to it without any understanding of why. Like the parable of the “Monkeys in a room with a ladder” experiment, “blindly following codified behaviour, without understanding why, is a trap”
For those who do not know the experiment: Several monkeys are placed in a room with a ladder and bananas at the top of the ladder. If one climbs, the group is punished, so the group learns “touch ladder = bad”. This is the beginning of best practices. “Our team made an observation, and we codified it” Over time, the rule is passed down as monkeys are removed and replaced, one day none of the monkeys ever experienced the punishment but they still follow “best practices”. They just don't know why.
The analogy can extend to almost any problem, any software, any team. “We are just following best practices”. So, what happens if a new ladder is introduced? What happens if you are in a different team on a different project, and your ladder is different? Is cautiously walking around the ladder the best idea or should you move the ladder?
A “best practice” is a rule created because of a past incident, within a specific team, within a specific project. Blindly following best practices at best causes work to be extended needlessly, and at worst hides the root cause of problems. For example: “100% unit test coverage”, on first implementation it ensured everything worked as expected. However as features were added and bugs were fixed, “100% test coverage” slowly became “50% test coverage, 50% compare 1 = 1”. Or was instated on to a team that began with 30% test coverage and did not have the resources to bring it up to 100% test coverage.
As I finished writing this, I remembered that while I on-boarded new starters, I taught our company's best practices but they were never called best practices. They were “the way we work within our systems” or “how we do things”. As I described “This is how you do X” I always explained why it was done in that way. “This is done in this way, because under the hood…” or “We do it this way, because we want to enforce a culture of…” it was not a simple check list of expectations.
I would only bring forward the cultural rules which I could explain. If someone asked me “Can you please make sure new starters are told to do…”, but they couldn't explain why, then I would challenge them to learn why.
If you are following “best practices”, ask yourself “what are the best practices? What exact problem was this best practice created to solve? Is it still relevant? Does it need to change?” Then, discuss it with your team. Adopt practices like engineers, not priests: state the problem they prevent, the constraints they assume, and when you'll review or back out. Retire any practice that doesn't demonstrably deliver value.