• Rally
  • Why best practices are not always the best decisions

Why best practices are not always the best decisions

By Sam Freund | December 28, 2018

It’s a fact of life: the bigger your company gets, the more you’re going to hear about “best practices,” in nearly every context, from art you put on your walls to coding standards and everything in between. Even at smaller companies at this point in the evolution of the tech startup, it’ll come up in conversation whether you like it or not.

I’m here to convince you that while it’s certainly worth understanding industry best practices and how we’ve arrived at them, in the technology world especially it’s not always the right choice to blindly follow those who have gone before. I’ll start off with some obvious examples outside of our sector and end with some other options that you can use to kickstart yourself into better than best.

When best practices really aren’t

“Never start a land war in Asia” and “Never go in against a Sicilian when death is on the line” are two well-known best practices made famous by The Princess Bride. Yet, if our hero (who as we know is pretty clever himself) always decided to follow best practices, the plot would have turned out remarkably differently. Moving into a more real-world example, if best practices were never questioned, we’d all still be smoking for good health.

Working at a health company, I can safely say I’m glad we’ve moved on from there! Similarly in the world of game theory, we have a long history of achieving local maxima for long periods of time. When AlphaGo first emerged as a serious contender, many experts scoffed at the moves it was making… until it managed to defeat every single one of those experts in turn, and now best practices in a game that has been around for centuries have changed.

The software industry is certainly no exception, either. There are hundreds of blog posts on best practices, coding standards, and more, and countless more Google hits that you can explore, if you’re feeling brave. Here’s a hint – they are not all identical, and there are lots of them, each claiming to be the best – so something has to give. If there were singularly perfect practices across the board, we wouldn’t still be having the tabs vs. spaces debate rage on today.

Innovation is stifled

Perhaps even worse, blindly following best practices is a good way to destroy your team’s innovation and creativity. “Because someone famous said so” and “because it’s the highest-rated answer on Stackoverflow” are great shortcuts – but they’re shortcuts. Sometimes they can get you where you need to go, but you’ll miss understanding the bigger picture of why they’re important. Accepting anything as the rule without exploring it goes against the scientific method, and is the source of many self-perpetuating bugs in software and errors in process.

If you find yourself following the crowd because it’s the crowd, and if you were to ask yourself why you’re doing it but can’t come up with any reason beyond that (I’m sure you can come up with a couple that the tech world is doing at the moment, generally speaking), you still might be doing the right thing, but you should really get to a place where you can prove and understand that you are doing the right thing.

When best practices really are

There’s good news. There are some best practices (or, for the sake of not being hyperbolic, let’s just call them excellent practices). “Don’t play in the busy street” is advice that I give my 8-year-old that has served him pretty well so far. Similarly, if you page through the “best practices” links that I asked you to look through above, you’ll find quite a few. Some of them are pretty good, no doubt! This time when you’re looking through them, keep an eye out for things you find yourself nodding about, things that would make your life (and the lives of your team) easier.

If you try it, and it does (and perhaps you’ve already executed on this process several times – great job! That’s an excellent practice!), then you know you’ve picked something good. If it adds overhead, underdelivers, makes code slow or unreadable or worse, you can always try again. (Remember that time I told you to be willing to fail? This is totally that.)

Focus your energy

But who am I kidding? You didn’t actually read 1.5 million hits on “best practices,” or at least I really hope you didn’t. In the real world, no one has time to wade through hundreds of possible timesavers, lifehacks, coding standards, and technologies to find the right one on the off chance it may help you a little bit. You need wins! Thus, instead of paging through dozens of articles on things that will barely move the needle, decide instead where to spend your time.

Make a list not of potential technologies or process tweaks to test, but rather a list of your absolute worst practices. Get help making your list, too – if you’re an engineering executive, your pain points are most definitely not going to be the same as an individual contributor on your team, or the same as those of the architect in the chair next to you, but all of your worst practices are impeding your common goal of delivering great software, which in turn is helping drive your higher-level success metrics whatever those may be.

If you’re an engineering leader, make your list and make sure everyone else’s list is part of it. Think of emails you get that make you say to yourself, “Again?” in frustration. Think of the last time someone asked about a problem on chat, only to have ten people jump on with “me too.” If it’s making someone upset, slow, or otherwise unable to deliver because something is getting in their way, get it on the list. (As an example, a while back we found that our build process was way too long and was slowing people down, forcing them to wait an unnecessary amount of time for things to build, leading to variants of this.

Now that you have your list, you can do your research: find a really good practice someone else is doing, or go your own way. Define success criteria for eliminating the problem, if it’s not obvious; what does a win look like? Use sage advice on how to combat the problems you’re facing, or at the very least what not to do about it. Perhaps most important, figure out the effect your efforts will have on the bottom line, as opposed to just iterating on something that already works for you – to truly move your overall bar, it’s far more effective to get something from a theoretical 20% to an 80% than it is to go from 80% to a 90% (I learned that from video games).

So go forth, and get better – don’t worry if you don’t get to best. And if you invent the next agile or the next database paradigm in the new year while you’re doing it, enjoy your fame and riches and please think of me.

Sam Freund