Against Best Practices

Often what is one developers "best practice" is another's "anti-pattern" because a lot of this is just arbitrary.

There are 2 main kinds of advice that get labeled best practices in an attempt at persuasion:

1. Advice which worked in one situation - “we tried Agile, everyone should use it!”

2. Proven stuff like code review, which you call best practices when begging your org to implement it: “please let’s do it, I can clearly see how this will improve our org.”

These 2 examples represent locations on a spectrum: let’s call it “provenness”.

The author’s problem boils down to subjectivity - everyone positions different practices in different places on the provenness axis. The upshot of that is when one person says “we should do this, it’s obvious and/or it’ll definitely help” another person hears “we tried it once, you should try it too!” and then everyone has a bad time.

Then it gets confounded by everyone calling everything best practices - no matter how long ago or unproven the practices might be.

What would be handy is some generally agreed-upon yardsticks for graduating practices into or out of best practices status, plus better terminology to cover the spectrum of provenness so more sophisticated discussions can be had that account for the nuance and we don’t all talk past each other..

But then analyst companies wouldn’t get to make their glossy 2x2 charts, so it probably won’t happen.

"Don't do X" is bad. "Don't do X because it's not a best practice" is less bad, but still bad. "Don't do X because Y" is good.

Only in the last one you can either understand the reason, or ignore the rule because it doesn't apply to your situation.

other engineering industries use standards that are good for stability but bad for efficiency and innovation.

Those approaches do work with programming, but they don't make use of what makes programming different from other disciplines.

Software is usually quick to write, update and deploy. And errors usually have pretty low impact. Sure, your website may be down for a day and people will get grumpy, but you can hack together a quick fix and have it online with the push of a button.

Compare that to, say, electrical engineering, where there's often a long time between finishing a design and getting a manufactured prototype (let alone mass production.) And a fault could mean damage to equipment (or people) and the cost of having to replace everything. So you'll find that there's a lot more work done up-front and the general way of working tends to be more cautious.

There's also the idea of best practices as a form of communication. This also helps for programmers, as code that looks and acts the way you expect it is easier to follow. But code is primarily shared with other programmers. Other engineering disciplines (more) frequently need to collaborate with people from other domains. For example, a civil engineer's work could be shared with architects, government bureaucrats and construction managers, and best practices often provide a common familiar standard.

Compared to other engineering disciplines, software is a big unorganized mess. But it's also incredibly fast and cheap to make because of that.