Best Practices Are Really Not

Let’s talk about best practices.

We always seek to improve. We always want to be better. And what is better than best?

Nothing!

So, we turn to best practices. If they are the best, we should be doing those things. Take for example, something that everyone in software considers a best practice: “Remove duplications”.

It’s like the first lesson, on the second day in software school. Don’t duplicate code.

And everyone (assuming they didn’t miss that lesson) can quote why you shouldn’t do this: If you create copies of your code, there will come a time when you want to change it. And then you’ll need to go to all the places and change it. That’s maintenance hell you don’t want to go through.

(By the way, I’ve postsed about code duplications before: clone wars, check it out.)

“Don’t Duplicate Code!” (From the Big Book of Best Practices)

Fine, but is it really a best practice? It’s a good news – bad news situation.
Let’s start with the bad news.

“Best practices” are not really the best.

Think about it – if they were really the best, everyone would be doing them by now, right? One reason not to, would be that they require some effort. But that’s not the only reason.

I mean, it’s not much effort to not copy code, right?

“Best” means best – better than all the other ways. Always. No matter the context. And unless we’re dealing with really simple stuff, context matters. Your best, and my best – they’re probably not the same. Because our problems, our processes, our history, our experience – they are not the same.

So what about those illusive “best practices”? What are we really looking for?

Simple. We’re looking for things that work for most people, most of the time. We lower our standards from “it works every time”, to “it will probably work for me”.

We’re willing to accept failure, although we don’t see it that way. I mean, if it’s the best practice, and it doesn’t work for me, I must be doing it wrong.

That may be true. And it is also possible that this almighty solution doesn’t solve my problem, or conflicts with other things. My context is different.

Best practices don’t really exist. What we’re after are “good enough practices”. While “best” is easy to put on a pedestal, those “good enough” ones? These are what we want.

And bonus points for them: They are a lot more easy to replace. Or sometimes, decide that they are not good enough.

So about that code duplication…

One of the best ways to remove code duplication it is to extract the code into a function, or a library. While it helps in maintenance (the reason for the principle), it may cause other issues – it may impact performance or readability.

Here’s another scenario where removing duplication may not be the right choice. Let’s say I work for a startup. I need to get quickly to something that “sort of works” to get feedback from customers. Whatever I’m writing, may be worth something, or not at all. Start-up life.

Should I remove duplications, investing in maintainable code, that may not see the end of the week?

You see? Context matters.

Once you you’ve taken the red pill, and understand that the “best practice” may not serve you, it will make you question other “best practices”. Which is not a bad idea, if you think about it.

After all, good enough, is, well, good enough.

Want more “good enough” practices? Check out my Clean Code workshop. It’s the best. For some context.