
Best Practices Are Not Always the Best - bloomca
https://blog.bloomca.me/2018/05/10/on-best-practices.html
======
tboyd47
> There are also tons of evangelists, which promote their
> technology/process/approach of choice, giving endless introductory talks and
> blogposts, but without answering complicated questions.

I find some programmers are very adamant that there's always a right way and a
wrong way to do something and you just have to examine the pros and the cons.
Well, what about when it's between a legacy codebase that no one on the team
has even spent half a day looking at and an idea that someone read on a blog
post that they never bothered to try? You can't honestly begin to identify
pros and cons in a situation like that. But this is how our industry is now.
So you kind of have to take claims of "best practices" with a grain of salt.

I don't even really engage in discussions on "best practices" anymore. Not
because I'm cynical, but because they just lead nowhere. Write some code that
runs, show it to me and we'll talk.

------
mlevental
you know what grinds my gears? when I go looking for help on a problem and the
answers I get are "don't do that it's not best practices". like not okay
here's how you do it but you shouldn't but just flat out I'm not going to tell
you. that's the most arrogant/presumptuous and consistent thing I've ever
dealt with and it's absolutely unique to software development. It completely
discounts the individuals personal experience (and abilities to make the right
decision for themselves) and their circumstances (the project itself) and it's
always around something dogmatic/a reflection of fanboyism. most recently on
#reactjs I wanted to know if there were a way to have locally scoped styles in
react like in Vue - I got only condescension about how react is for "bigboys"
and hence eschews the practice. Finally someone said hey maybe try styled-
components, which was basically close enough and has 16,000 stars on GitHub
(so I doubt it's "worst practices"). software devs are some of the most
zealous people I've ever met - everything is an opportunity to bike shed and
every question or difference of opinion is an opportunity to quarterback
someone else's code base.

~~~
Retric
Best practices are a very wide category, don't parse HTML with regular
expressions is the kind of thing you really should just say don't do that.
Camelcase is the middle ground where it's a good idea but personal preference
may show up yet people get just as dogmatic about it.

IMO, what trips people up is when wisdom says "don't use Oracle products" it's
completely accurate, but not that helpful when you inherit a huge mess.

~~~
coldtea
> _Best practices are a very wide category, don 't parse HTML with regular
> expressions is the kind of thing you really should just say don't do that._

I call BS.

"Don't have a continuously running service parse arbitrary HTML with regular
expressions" would be a bad thing.

Parsing specific, given, HTML files, with known structure to the dev, with
regular expressions (e.g. as part of a one-off scrapping script) is totally,
absolutely, fine.

If my HTML file is like:

    
    
      <html>
      <body>
      <a href="xxxxx">foo</a><br>
      <a href="xxxxx">foo</a><br>
      <a href="xxxxx">foo</a><br>
      <a href="xxxxx">foo</a><br>
      <a href="xxxxx">foo</a><br>
      <a href="xxxxx">foo</a><br>
      <a href="xxxxx">foo</a><br>
      </body>
      </html>
    

I can parse it just fine with regex.

And even parsing is the wrong word: I can extract the information I want is a
better term. I won't be parsing anything in the AST sense.

~~~
phil21
As someone who has created more hacks like you describe than I care to admit,
you actually make the case of precisely why you _don 't_ parse HTML with
regex.

Because that code works fine for 5 years until it blows up after something
upstream changes. From a RoI calculation this might be perfectly fine if
you're still around and remember how to fix it - it's a 5 minute fix after
all! But if you've left, or if that system became old and crufty and fragile
you may have just burned 3 days tracking it down.

If someone is asking this question, it is entirely appropriate to tell them
"don't ever do that" \- they obviously lack the experience and big picture
thinking to know when it _is_ appropriate to deviate due to business reasons.
If you leave it at that I agree you're being a dick - whenever shooting
someone's idea down you had damn well better have some appropriate alternative
options.

~~~
jerf
"Because that code works fine for 5 years until it blows up after something
upstream changes."

I believe the point here is exactly that nothing _will_ change, because the
regex in question isn't for a service, it is just for _that specific file_ ,
right now, today. I've regexed specific HTML files myself too, because even
though I am very comfortable with XPath and Beautiful Soup and tree
representations in general, regexes are even easier on a static file like
that.

~~~
pwinnski
When I was young, I was asked to print some address labels, so I wrote a quick
super-short BASIC program to parse a specific file, right now, today, and got
those labels printed. Made all sorts of assumptions, but it didn't matter,
because it was a static file, and nothing could ever change in it.

Three or four years later, I was having lunch with the guy I'd done that for
when he got a phone call. Turns out they were using that program of mine to
print labels monthly now, and one of the completely-safe assumptions I'd made
years earlier had bitten them. Fortunately, he knew how to resolve it easily,
but I learned a very important lesson that day.

~~~
noobiemcfoob
What lesson was that?

From my perspective, this other guy was using a program outside of its design
spec. That can be fine, but such a thing is prone to the problem of safe
assumptions suddenly not being safe. You wrote the program for the problem you
needed it for, and for which, it worked fine. Unless part of the problem at
the time was "we expect to use this program for a couple years", there is no
reason to make it overly robust.

~~~
Retric
"right now, today" and "that specific file"

Code designed to be used once has a habit of sticking around.

~~~
coldtea
[https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it](https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it)

~~~
Retric
There is premature optimization and then there is not being stupid. Using one
of the 10,000 XML/HTML parsers to get to v0.01 takes about as long on average
and avoid ridiculous problems.

The only thing regex has going for it is you might already know it. But, this
is one of those time when learning something _is worth it._

PS: XP is doing a depth first search, which can be EXtreamly wasteful.

------
andygcook
We’ve iterated on our process quite a bit for my startup. I agree that
sometimes you need a completely new approach, but more often than not what
already works for another team will most likely work for us with some small
tweaks. What I find works pretty well is to think about the problem, apply our
existing knowledge and experiences to the solution, make any obvious edits for
our unique, then test it out. From there, we make tweaks if needed to get to
what works, or we completely scrap what we know and try something completely
new. Process, like product, requires iteration. But process is also built off
conventions and modeled off core human behaviors. Chances are the wheel
doesn’t need to be completely reinvented. My advice would be to fork what
works on the process side, and use all your creative energy to come up with
something new on the product side.

~~~
majewsky
I suggest that you work on making your statements more punctual. For example,
if I'm not missing anything, all of this could be shortened to:

> We apply best practices most of the time to save time, but we usually tweak
> them for our concrete situation. Be sure to spend most of your energy on
> your core competence instead of bikeshedding over processes.

------
quantumhobbit
Evertime I hear someone defend something as a best practice without any other
justification, I mentally switch “best practice” with “cargo culting” and lose
no information.

Sometimes the best practice in question does have value and can be
articulated. But in those cases the articulated reason makes a better argument
and you don’t hear the phrase “best practice” quite as often. When it is just
cargo culting, the only defense is to repeat “best practice” over and over
again.

~~~
vorpalhex
I prefer to think of the term as "sensible default". A "best practice" is
_usually_ not the worst default to have, and if you don't have the time or
bandwidth to dive into a problem and just want to pick a solution from a hat,
you could do a lot worse.

The danger comes in that when you want to supplant the best practice with a
new practice, you have to genuinely understand the problem in your context,
and be able to articulate a full explanation about why the new practice has an
advantage.

But there is definitely cargo culting around best practices - see using Redux.
Core features of your app shouldn't be left to just acceptable defaults, but
instead you should grapple with those problems and choose the best possible
answer you can at the time.

~~~
SketchySeaBeast
>The danger comes in that when you want to supplant the best practice with a
new practice, you have to genuinely understand the problem in your context,
and be able to articulate a full explanation about why the new practice has an
advantage.

We're experiencing that exact problem - we're introducing for the first time a
company wide best practice, which isn't even defined yet and in a constant
state of flux, but it's become a shield the strongest evangelists stand behind
"why would you want to do that? It's not best practice?" \- the "best
practice" might not last the month, and it's not clear why that's the "best
practice", but it's become a magic seal of approval.

------
Noumenon72
Two years into my programming career, there's still almost nothing I do that
isn't just implementing the best way someone else thought to do it. And I
still have a lot more to learn before I would start off on my own. My only
problem with best practices is that sometimes there are too many and living up
to them all would take all your time. And some of them are just evangelists
for niche ideas and it's hard to tell.

------
shubhamjain
"Don't use Goto," "Don't use Regex against HTML." Worse than not following
best practices is accepting it without demur. The insight dawned upon when I
learned how Chromium's team doesn't use continuous branching. The codebase
moves so fast that committing to a single branch is a much better option [1].
I highly doubt Google's engineers made that choice out of sloppiness.

Although, I think it's not simple to foresee long-term implications of our
decisions. And, best practices do fill that hole. At the same time,
programmers should keep an open mind to use a solution if it's a radically
simpler choice.

[1]: [https://medium.com/@aboodman/in-march-2011-i-drafted-an-
arti...](https://medium.com/@aboodman/in-march-2011-i-drafted-an-article-
explaining-how-the-team-responsible-for-google-chrome-ships-c479ba623a1b)

------
peterwwillis
This wikipedia page explains the nuance of best practice:
[https://en.wikipedia.org/wiki/Best_practice](https://en.wikipedia.org/wiki/Best_practice)

Not following best practices is more likely to result in inefficiency. But the
key word here is "practice".

Practice dancing a lot and you will be able to dance well, in the form of
dancing you practiced. There are other forms of dance and thus other forms of
practice. Practice for lindy hop is going to differ from practice for tango,
or jazz. And the _best_ practice for lindy will result in the best lindy
dancing, as it has been developed over time and has the best outcomes.

But if for some reason you need to do lindy hop in, say, a _really_ cramped
space, the practice will have to change. Best practice doesn't mean only
practice.

------
collyw
One benefit of best practices is standardizing the way things are done. I have
worked on project where the original developer had invented a "thin models fat
controllers" philosophy for Django (best practices are fat models thin
controllers). What a mess that was.....

------
pasbesoin
When they moved us, programmers and related staff, to "cubettes" \-- not even
full cubes, but rather a corner in a shared three-sided "pen" with low walls.
Your neighbor's shoulder three to five feet away from you. Cube meetings
crowding into their half of the pen. Conversations shouted willy-nilly across
the open floor plan.

They called that the "best practice".

"Best" is in the eyes of whoever's calling it a "best practice".

------
xojp123
Being a tad pedantic and agree with the spirit of the article, but this just
seems like a result from the overuse of the phrase 'best practices'.

~~~
epicide
Exactly. "Best" practices don't always turn out to be the best, after all.
"Better" practice might be a better (heh) fit.

It's often more useful to look at anti-patterns and avoid those (still with a
grain of salt) than it is to go looking for a pre-existing "best" solution to
your specific problem.

~~~
coldcode
Don't get me started on the other best, "Best of Breed". Nothing in software
or programming is a binary system, best and dreadful.

------
watertom
Best practices = minimally acceptable

If everyone is doing it. how can it possible make you the best?

------
DrNuke
b2b business is based upon best practices though, you cannot have a startup
mentality (hack or disrupt) when its legal consequences would outrisk the
possible gain

