Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Best Practices Are Not Always the Best

blog.bloomca.me

Post reply on HN
Print view View original

41–50 of 61 posts

Re: Best Practices Are Not Always the Best

#41

Post by nix0n »

Retric wrote: post #5
mlevental wrote: post #2

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 exp…

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 hu…

> you really should just say don't do that

This is counterproductive unless you also say what to do instead.

Re: Best Practices Are Not Always the Best

#42

Post by majewsky »

watwut wrote: post #34
phil21 wrote: post #26

Earlier quoted context omitted.

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…

There are plenty of disposable code situations where the code wont break after 5 years, because it does not exist after two months. Also, failing regexp on likely generated html like that likely wont take 3 days to find. That is ridiculously high estimate even for messy codebase. You are trying to make estimates and decisions for project you know literally nothing about. That is about worst practice of them all. In c…

> failing regexp on likely generated html like that likely wont take 3 days to find

This is true, but only because you're implying that the reason (failing regexp on HTML input) has already been identified. Maybe the parsing job fails silently and then people down the line (who have no idea that the data was passed around as HTML at some point) wonder why no data is coming in anymore, or why they're seeing incomplete data. That could take weeks to trace back to the parsing problem.

Re: Best Practices Are Not Always the Best

#43

Post by peterwwillis »

This wikipedia page explains the nuance of 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.

Re: Best Practices Are Not Always the Best

#44

Post by watwut »

majewsky wrote: post #42
watwut wrote: post #34

Earlier quoted context omitted.

There are plenty of disposable code situations where the code wont break after 5 years, because it does not exist after two months. Also, failing regexp on likely generated html like that likely wont take 3 days to find. That is ridiculously high estimate even for messy codebase. You are trying to make estimates and decisions for project you know literally nothing about. That is about worst practice of them all. In c…

> failing regexp on likely generated html like that likely wont take 3 days to find This is true, but only because you're implying that the reason (failing regexp on HTML input) has already been identified. Maybe the parsing job fails silently and then people down the line (who have no idea that the data was passed around as HTML at some point) wonder why no data is coming in anymore, or why they're seeing incomplete…

Silent failure seems to be root cause of delay in situation you described. Ast based parsing can be made to swallow errrors too.

Re: Best Practices Are Not Always the Best

#45

Post by specialist »

jrs95 wrote: post #7
mlevental wrote: post #2

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 exp…

Sounds like the community might be a reason to use Vue over React ;) In all seriousness this is a problem I've run into before as well. I once reported a bug and the lead developer of the project responded saying he didn't think the bug existed. Setting the hostname in the config to the server's IP address was irreversible even if you change it later -- the site would redirect back to the raw IP and outgoing emails w…

Grrr.

I’ve always designed away the sharp edges. Because I don’t want the 4:00a wake up call from panicky customers.

Which is why all my devs also did rotations in tech supp, QA/test, build monkey, etc.

Re: Best Practices Are Not Always the Best

#46

Post by majewsky »

andygcook wrote: post #3

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…

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.

Re: Best Practices Are Not Always the Best

#47

Post by dvanduzer »

pwinnski wrote: post #37
jerf wrote: post #31

Earlier quoted context omitted.

"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, rege…

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 wer…

Was the lesson that there's a fortune to be made in software maintenance?

Re: Best Practices Are Not Always the Best

#48

Post by titanix2 »

coldtea wrote: post #11
Retric wrote: post #5

Earlier quoted context omitted.

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 hu…

> 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 totall…

In the case of processing HTML with regex there is a strong theoretical argument against it: a regular expression is a type 3 language while HTML is described by a type 2 grammar. Type 3 being a subset of type 2, regular expressions are not expressives enough to handle the grammar of HTML.

In most cases of best practices however, such a mathematical argument doesn't exist. So, it's more of a battle of (not so) informed technical opinions and experiences, where drawing a clear line is impossible.

Reading list:

https://en.wikipedia.org/wiki/Chomsky_hierarchy

https://stackoverflow.com/a/14207715

Re: Best Practices Are Not Always the Best

#49

Post by noobiemcfoob »

pwinnski wrote: post #37
jerf wrote: post #31

Earlier quoted context omitted.

"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, rege…

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 wer…

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.

Re: Best Practices Are Not Always the Best

#50

Post by SketchySeaBeast »

vorpalhex wrote: post #27
quantumhobbit wrote: post #23

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…

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 ar…

>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.

Post reply on HN