If you look at an industry way of doing something and decide it’s wrong, you should have solid reasoning to back it up.
I’ve seen so many companies decide that they have some unique requirement to do X that every other company out there doing X doesn’t have. It leads to reinventing the wheel, but generally in a worse way.
All that said, the most dangerous words in engineering are “because we’ve always done it that way”.
I agree! Now can we also agree that often what is touted as "best practice" is not industry practice, but rather built on "authority" as the article rightly claims?
The number one thing I hate about "best" practices is it heavily implies there is one and only one "correct" way to do things, and every other way is wrong.
Is SOA appropriate to every org? What does it solve or permit? Is it appropriate at the scale of a system with 10 developer? Or does it become effective at some scale between 10 and Amazon?
Much of industry treats git as the de facto version control system. Why not another system? What makes git better overall or is it?
While I'm a massive proponent of unit testing, there are systems where they're actually very impractical. Should we contort our software and environment to support a popular, best practice testing method when neither support it in their existing or natural states?
Should everyone really be contorting HTTP to be the base protocol for every application? Does it make sense as a messaging system protocol? As your email protocol? Would more dedicated protocols be better?
Best practices aren't the same depending on the caliber of the engineers you have.
Here's one: if you copy them in every way, you'll just be a smaller and later version of them and get no users or sales. A-priori, you're going to need to find an edge somewhere.
And I'd further counter that: yeah, actually, you and your company ARE special. Every company is. There is no One True Way of running a business, or any individual aspect of that business. Everyone's triangulating around resources, people, industry, corporate vision, etc. If anything I'd say the argument that "you are not special" is the fallacy, as it leads directly to the kind of cargo-culting that you see so many failed companies do.
Finally, when we see successful companies, how often is it because they just mimicked what everyone else was doing? Not very frequently, as it turns out. Well-behaved companies seldom make history.
I don' think this is quite right - it's probably important to do something differently, but likely equally important not to do too much differently.
They never do.
I recall talking to someone who was very very happy to brag that his company was doing "everything just like Google" and following the exact same practices he read the company did on various engineering blogs.
I asked him what was the compensation like and how he managed to get kids from Stanford to work at his company instead of their startups and he just gave me a blank stare. Said something about how they were not in Silicon Valley and paid median salaries and that he had "no trouble finding Google caliber talent in the local market." and that "it's not really the local market's customs to give stocks to coders".
I think someone ended up buying the whole thing. Not the company but the office furniture they left after going broke.
Absolutely make your USP special.
But logging? DB access? Deployment? Those are generally solved problems and unless you have a very good reason not to... "doing what everyone else does" is going to be a lot less pain in the long run.