←back to thread

Against Best Practices

(www.arp242.net)
279 points ingve | 5 comments | 18 Nov 24 07:45 UTC | HN request time: 0.001s | 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. grey-area ◴[18 Nov 24 11:04 UTC] No.42171370[source]▶
Other engineering disciplines have certification, codes and regulations for specific domains, which are enforced by law.

DRY is a perfect example though of something which in moderation is a good idea but as the article says is vulnerable to ‘inexperienced programmers who lack the ability to judge the applicability’ and if over-eagerly applied leads to over-abstraction and premature abstraction which does more harm than good.

replies(2): >>42173935 #>>42174524 #
2. mrkeen ◴[18 Nov 24 16:24 UTC] No.42173935[source]▶
>> inexperienced programmers who lack the ability to judge the applicability

In other words, the author knows better than you.

The author could have put forward precedent, principles, or examples. But instead he chose to make it about the people (inexperienced), not his arguments.

replies(1): >>42174345 #
3. yCombLinks ◴[18 Nov 24 17:01 UTC] No.42174345[source]▶
The point is there are not rules that are always applicable. Dry is right sometimes, and sometimes it's not.
4. HelloNurse ◴[18 Nov 24 17:15 UTC] No.42174524[source]▶
Before regulations, other engineering disciplines have far more objective decisions and calculations than software engineering. Consider a mechanical analogue of DRY: choosing between reusing identical parts to make design, assembly and repairs simpler or designing similar but different parts because they are worth optimizing (e.g. a whole IKEA cabinet with interchangeable screws or with short and long ones). Unlike next month's shifting software requirements the cost and performance of this kind of alternative can be predicted easily and accurately, without involving gut feelings or authority.
replies(1): >>42177722 #
5. grey-area ◴[18 Nov 24 22:17 UTC] No.42177722[source]▶
Well I think the point is you can’t legislate on things like style, or at least it is pointless to do so and other disciplines don’t try to. DRY is a style guideline.

What you can legislate/codify are procedures, safety and outcomes. So for example building designs must be signed off by a structural engineer and architect, both of whom are liable if the buildings collapses and kills someone. There are standards materials must meet and for which materials can be used. Buildings must meet standards for fire protection, air flow, heat loss etc.

I’m not sure software is at the stage where we even know what to codify or what is good and what is not good.