←back to thread

Against Best Practices

(www.arp242.net)
279 points ingve | 3 comments | 18 Nov 24 07:45 UTC | HN request time: 0s | source
Show context
vbezhenar ◴[18 Nov 24 10:49 UTC] No.42171296[source]▶
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 lines sometimes, but that's a good compromise.

May be there should be a good compromise when it comes to "best practices"? Like "DRY" is not always best, but it's always good enough, so extract common stuff every time, even if you feel it's not worth it.

I often deal with this dilemma when writing Java with default Idea inspections. They highlight duplicated code and now I need to either disable this inspection in some way or extract the chunk of code that I don't really think should be extracted, but I just can do it and move on...

replies(12): >>42171363 #>>42171370 #>>42171393 #>>42171459 #>>42171531 #>>42171554 #>>42171817 #>>42171829 #>>42172784 #>>42173289 #>>42173799 #>>42174046 #
1. heavypixels ◴[18 Nov 24 11:35 UTC] No.42171531[source]▶
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.

replies(1): >>42171590 #
2. gpderetta ◴[18 Nov 24 11:46 UTC] No.42171590[source]▶
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.

replies(1): >>42172402 #
3. LandR ◴[18 Nov 24 14:11 UTC] No.42172402[source]▶
> It is just that high-velocity low-reliability web and consumer application development is a very large niche

And most of them have no care about the user experience of the end user at all.

Almost every piece of software I have to interact with on a daily basis is absolute garbage. Just full of frustrating bugs that makes most of my day when I'm forced to use a computer absolutely miserable. But to each of the devs it's just a small annoyance in their particular app. Not caring to the end user it's one annoyance that leads to a death by a thousand cuts.

Software is just atrocious nowadays.