Trying to follow all best practices will not help you

Jean-Michel 🕵🏻‍♂️ Fayard - Sep 27 '19 - - Dev Community

I think that best practices are overrated for a number of reasons.

  • Best practices are like standards, they are good because there are so many you can choose from. Like parental advice, they cover every single aspect of what you do, contradict each other and tend to get on your nerves.
  • Best practices tend to make people forget that "Rom was not built in a day". They can easily become overwhelming. In the Android world, you have people telling you to follow their TODO-MVC app that use Dagger+Architecture-Components+Clean-Architecture+Room+AndroiX+ConstraintLayout+RxJava+SingleActivity+DeepLinks+MVI+Y+Z+A+B. This is so terrible.
  • Best practices are context-free advice. Facebook had some problems, so clever people there found a solution for it. Now everybody is cargo-culting it. But actually most of the followers are not Facebook, so They Are Not Going To Need it.
  • Doing the right things is more important doing things right. You can follow all best practices on earth and still produce something that brings no value to the world. Not convinced? Check out https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
  • There is an un-recognized trade-off between best practices and simplicity. It seems a no-brainer to say "I follow best practices". Wouldn't it feel weird to say the contrary? But what about "I value simplicity and solving problems when they actually occur"? As Joel Spolsky warned us: Don’t Let Architecture Astronauts Scare You
  • Note that the previous item is not a "best practice" that you should apply blindly. There is a reason I put on my profile: "Weeks of programming can save hours of planning". Security for example cannot be an afterthought. If your initial API design is bad, you are stuck with it forever, see my article Android's billion-dollar mistake(s)
  • Best practices make us focus on the wrong thing. Nothing waste a team time and energy better than having to argue on for example what is right git flow?. Instead of focusing on the HOW, we should start with WHY?. Invest time in your context. Why is this feature important? Which pain point are we trying to solve?

Best practices are shared with good intentions.
After all, we all want to produce good work, no?

So what could we replace them with?

My answer would be: don't tell me about your solutions, tell me about your problems. Raising the awareness of a problem I may have is really helpful. Copy/pasting your solution in another context, often not so.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Terabox Video Player