←back to thread

Against Best Practices

(www.arp242.net)
279 points ingve | 1 comments | 18 Nov 24 07:45 UTC | HN request time: 0.219s | source
Show context
agentultra ◴[18 Nov 24 14:14 UTC] No.42172433[source]▶
I think the rejection is too strong in this article. The idea of, “best practices,” comes from an established Body of Knowledge. There is one published for software development called the SoftWare Engineering Body of Knowledge or SWEBOK; published by the IEEE.

The author seems to be arguing for nuance: that these “laws,” require context and shouldn’t be applied blindly. I agree.

However they shouldn’t be rejected out of hand either and people recommending them aren’t idiots.

Update: one problem with “best practices,” that I think the article might have unwittingly implied is that most software developers aren’t aware of SWEBOK and are repeating maxims and aphorisms they heard from others. Software development is often powered by folklore and hand waving.

replies(7): >>42172691 #>>42173545 #>>42175036 #>>42175396 #>>42176186 #>>42177350 #>>42178640 #
SoftTalker ◴[18 Nov 24 21:36 UTC] No.42177350[source]▶
To put it simply, best practices are, at best, context-dependent. Best practices for avionics software are not the same as best practices for a CRUD form on your mailing-list signup page.

And to be fair, the best practices for designing a bridge or a skyscraper are not the same ones for designing a doghouse.

replies(2): >>42177708 #>>42179749 #
1. jrs235 ◴[18 Nov 24 22:15 UTC] No.42177708[source]▶
This! "Best practice" depends on the circumstances. Are "micro services" a best practice? What about "monolithic architecture"? Those choices are not best practices in and of themselves but may be best practices when considering organization/dev team size, application user count, computational demands on the application/system, etc. What are the goals and vision of the future? Let's future-proof and pre-optimize for problems we don't currently have nor will likely have! (And don't get me started on the number of folks that dream about "we're going to need to be able to scale!" for a fairly simple CRUD app that will most likely be used by hundreads, maybe thousands, or users and realistically need 100's of "simple" requests per second (most likely per minute... )