Trying to follow all best practices will not help you

jmfayard profile image Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄ Updated on ・2 min read

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.


Editor guide

Many engineers tend to follow "best practices" blindly, without clear understanding why they did appear and under which conditions they are applicable.


Yes, and I think it's due to perfectionism, due to the fear to not do things right.
My counter-argument is that it's more important to work on the right things that to do thing right, and once you have found the right thing, choose whatever simplest solution you can find.


I saw different reasons for blind following best practices. For some engineers it's perfectionism. For others it's the fear not to "be in trend". Former ones over the time usually develop habit to "find the root" and stop using anything blindly. Latter ones don't need that, "be in trend" is enough to pass interview and get the job.