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

Against Best Practices

arp242.net

Post reply on HN
Print view View original

21–30 of 218 posts

Re: Against Best Practices

#21

Post by federiconafria »

vbezhenar wrote: post #2

How other engineering industries deal with this phenomena? Why those approach do not work with programming? I feel silly sometimes because software development is huge industry and we don't have consensus on basics. For example I think that strict formatting is a good thing. Since I tried to use Prettier I'm using it and similar tools everywhere and I like it. I can't do vertical alignment anymore, it eats empty line…

I think one thing the industry does not do properly is applying different practices and standards depending on context.

An retailer website is not the same as a trading platform, the same way that a house is not the same as a railway station. But we blindly try to apply the same "good practices" everywhere.

We also have another interesting phenomenon, our products can mutate in their lifetime, and our practices should follow (they often don't) an MVP can become a critical system, a small internal project can become a client-facing application, we can re-platform, re-write, etc. That's very rare in other industries.

Re: Against Best Practices

#22

Post by pletnes »

ohthatsnotright wrote: post #11
larsrc wrote: post #6

Follow best practices unless you can give a reason not to. "Best practice" is a shorthand for a lot of accumulated knowledge that you don't want to go over again every time. Also following BP makes the code more consistent and thus easier to understand. But when an argument arises, go back to the underpinnings of the best practice and work from there.

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

Hot take, the biggest advantage to following «best practices» is that when someone else stumbles over your project, they can follow along more easily

Re: Against Best Practices

#23

Post by Angostura »

ohthatsnotright wrote: post #11
larsrc wrote: post #6

Follow best practices unless you can give a reason not to. "Best practice" is a shorthand for a lot of accumulated knowledge that you don't want to go over again every time. Also following BP makes the code more consistent and thus easier to understand. But when an argument arises, go back to the underpinnings of the best practice and work from there.

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

If it is arbitrary, it’s “standard practice”.

Re: Against Best Practices

#24

Post by tajd »

larsrc wrote: post #6

Follow best practices unless you can give a reason not to. "Best practice" is a shorthand for a lot of accumulated knowledge that you don't want to go over again every time. Also following BP makes the code more consistent and thus easier to understand. But when an argument arises, go back to the underpinnings of the best practice and work from there.

Yeah exactly.

A lot of the time best practice can also mean “we did it this way last time and it was ok”. I don’t think anyone is saying don’t find improvements in “what is currently defined as best practice” and if they are then that’s your problem.

Re: Against Best Practices

#25

Post by gpderetta »

heavypixels wrote: post #19
vbezhenar wrote: post #2

How other engineering industries deal with this phenomena? Why those approach do not work with programming? I feel silly sometimes because software development is huge industry and we don't have consensus on basics. For example I think that strict formatting is a good thing. Since I tried to use Prettier I'm using it and similar tools everywhere and I like it. I can't do vertical alignment anymore, it eats empty line…

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

You can destroy rockets, lethally irradiate people, fly planes upside down, or financially ruin a company because of software bugs, so avoid faults can be critical for software as well.

It is just that high-velocity low-reliability web and consumer application development is a very large niche. A lot of our best-practices are about attempting to maintain high velocity (often with questionable results), more than increasing reliability.

Re: Against Best Practices

#26

Post by pydry »

ohthatsnotright wrote: post #11
larsrc wrote: post #6

Follow best practices unless you can give a reason not to. "Best practice" is a shorthand for a lot of accumulated knowledge that you don't want to go over again every time. Also following BP makes the code more consistent and thus easier to understand. But when an argument arises, go back to the underpinnings of the best practice and work from there.

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

There are many like that. Every practice is a trade off.

However, there are many where the cost/benefit ratio is so large that you can default to "you should just do this".

I dont think Id ever look at a company that e.g. had no CI or versioning for a large project for instance and think "they might have had a good reason for this". They didnt.

Re: Against Best Practices

#27

Post by ahoka »

ohthatsnotright wrote: post #11
larsrc wrote: post #6

Follow best practices unless you can give a reason not to. "Best practice" is a shorthand for a lot of accumulated knowledge that you don't want to go over again every time. Also following BP makes the code more consistent and thus easier to understand. But when an argument arises, go back to the underpinnings of the best practice and work from there.

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

There’s usually nothing “best” about it.

Re: Against Best Practices

#28

Post by muro »

f1shy wrote: post #8
larsrc wrote: post #6

Follow best practices unless you can give a reason not to. "Best practice" is a shorthand for a lot of accumulated knowledge that you don't want to go over again every time. Also following BP makes the code more consistent and thus easier to understand. But when an argument arises, go back to the underpinnings of the best practice and work from there.

Basically if you know exactly why the best practice/rule is in place, and know for sure it does not apply, just skip it. But not before. https://en.wiktionary.org/wiki/Chesterton%27s_fence

That's very reasonable.

‘The reasonable man adapts himself to the world; the unreasonable man persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.’

Re: Against Best Practices

#29

Post by taeric »

Best practices are tough for practices where the foundations are not stable. And with programming, we have trouble defining the foundations. Much less stabilizing them.

And note I don't mean stable as in, not crashing. I mean it as not changing.

For a while, this was doable with java. For its warts, it gave a good foundation. Industry practice got caught up in start up enthusiasm, though, and that went out the window.

Similar could probably be said for Windows. I was not a fan of its model, but it provided a stable base for business apps for a long time.

Post reply on HN