[HN Gopher] Against Best Practices
___________________________________________________________________
Against Best Practices
Author : ingve
Score : 187 points
Date : 2024-11-18 07:45 UTC (15 hours ago)
(HTM) web link (www.arp242.net)
(TXT) w3m dump (www.arp242.net)
| vbezhenar wrote:
| 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...
| reverius42 wrote:
| I think we're still in the "phlogiston" era of software
| development.
| ben_w wrote:
| That good?
|
| I think we're more like Pythagoras: some useful theory about
| numbers, taken way too far and became an actual religion[0]
| listening to the Delphic[1] Oracle[2].
|
| [0] Tabs or spaces? Vi or emacs? Is the singularity the
| rapture of the nerds, with Roko's Basalisk as the devil and
| ${insert name here according to personal taste} as the
| antichrist? SOLID or move fast and break things?
|
| vs. really a real religion:
| https://en.wikipedia.org/wiki/Pythagoreanism
|
| [1] Not https://en.wikipedia.org/wiki/Delphi_(software)
|
| but rather https://en.wikipedia.org/wiki/Delphi
|
| [2] Not https://en.wikipedia.org/wiki/Oracle_Corporation
|
| but rather https://en.wikipedia.org/wiki/Oracle
| grey-area wrote:
| 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.
| mrkeen wrote:
| >> 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.
| yCombLinks wrote:
| The point is there are not rules that are always
| applicable. Dry is right sometimes, and sometimes it's not.
| HelloNurse wrote:
| 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.
| grey-area wrote:
| 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.
| f1shy wrote:
| Some reasons I would say:
|
| - I think SW needs much more creativity than other industries.
|
| - Typically SW is not mission critical (in mission critical
| things, it IS pretty much regulated to uncomfortable extremes)
|
| You _could_ regulate it to death, and would probably have some
| positive impact by some metric, but you would be easily
| overtaken by FOSS, where for sure there will be less
| restrictions.
| cowl wrote:
| other engineering industries use standards that are good for
| stability but bad for efficiency and innovation.
| heavypixels wrote:
| 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.
| gpderetta wrote:
| 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.
| LandR wrote:
| > 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.
| federiconafria wrote:
| 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.
| cjblomqvist wrote:
| A nit; DRY is probably not what you think it is. DRY is
| basically the same as SRP, framed differently. In SRP, it's
| totally valid to have the code twice if it has different
| meaning from a user pov.
| begueradj wrote:
| Quoted: "You can still not repeat yourself but violate single
| responsibility"
|
| (https://softwareengineering.stackexchange.com/questions/2207
| ...)
| vbezhenar wrote:
| The problem with definition is that it's subjective and
| cannot be checked automatically. So my definition was about
| mechanistic DRY, which is objective and checked by linter.
| taeric wrote:
| What makes you so sure they do? Go to the hardware store and
| behold how many fasteners there are. Go down the rabbet hole of
| pipe fittings. Consider the optimal size of lumber, someday.
|
| And then get ready for the horrors of electrical connections.
| Not necessarily in how many there are; the real horror is how
| many think there is a "one true answer" there.
|
| You can find some solace in learning of focusing effects. But,
| focus isn't just getting harder for individuals. :(
| whstl wrote:
| That's a great point.
|
| In the end, other engineering areas also have lots of "it
| depends" situations, where often there are multiple correct
| answers, depending on availability, legislation, safety,
| physical constraints, etc.
|
| Perhaps in software engineering people are just too quick or
| immature to judge.
|
| > rabbet hole
|
| Nice pun ;)
| randomdata wrote:
| _> How other engineering industries deal with this phenomena?_
|
| They don't. CAD, the "programming languages" of most other
| engineering disciplines, is as much of a Wild West.
| marcosdumay wrote:
| "Engineering industry" is a misnomer. Other engineering areas
| have the same issues with best practices we have, industries
| apply best practices with a great amount of success (but not to
| totality).
|
| Usually, engineering creates best practices for the industries
| to follow.
| toast0 wrote:
| > How other engineering industries deal with this phenomena?
| Why those approach do not work with programming?
|
| A lot of engineering discipline is a way to prevent engineered
| works from causing unintentional injury, physical or fiscal.
|
| Most software development is far away from physical injury. And
| fiscal injury from software failure is rarely assigned to any
| party.
|
| There's no feedback loop to push us to standardized process to
| cover our asses; we'd all prefer to do things our own way. It's
| also pretty hard to do convincing studies to determine which
| methods are better. Few people are convinced by any of the
| studies; and there's not been a lot of company X dominates the
| industry because of practice Y kinds of things, like you see
| with say Toyota's quality practices in the 80s and 90s.
| chris_wot wrote:
| It occurs to me that the author is explaining his best practice
| is to look at someone else's best practice with a gimlet eye and
| take what you want from it. So I wonder how to apply his best
| practice to his own best practice?
| larsrc wrote:
| 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.
| f1shy wrote:
| 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
| muro wrote:
| 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.'
| lolinder wrote:
| > Therefore all progress depends on the unreasonable man.
|
| The unfortunate corollary to this is that all retrogression
| also depends on the unreasonable man. The reasonable person
| (as defined here) maintains the status quo, for good or
| ill.
| throw310822 wrote:
| I would reverse this: if you can explain to me exactly why
| your so called "best practice" applies here and now, good.
| Otherwise it's a nice input to have in the discussion, but
| nothing more.
| nine_k wrote:
| It depends on your risk appetite. A best practice likely
| keeps you away from pitfalls known to the community of the
| practice but not to you. It also may keep you away from
| crafting a solution that is optimal for your specific
| circumstances not known or applicable more widely.
|
| In high-reward / low-risk environment, such as building an
| indie turn-based retro-style game, go with your gut feeling
| unless you have a good reason not to.
|
| In a high-risk / dubious-reward environment, such as
| implementing cryptography, follow the best practices to a
| t, unless you know intimately how things work and maybe
| codified some of the practices.
|
| There is a wide gamut between these two extremes.
| throw310822 wrote:
| > A best practice likely keeps you away from pitfalls
| known to the community of the practice but not to you.
|
| In my experience, many "best practices" _are_ the
| pitfalls you should be wary about, as they can easily
| translate into hundreds or thousands of lost hours of
| work and derail and doom entire projects. (The most
| annoying part of this is that the real causes won 't be
| found, precisely because "best practices have been
| followed". Therefore the reputation of the best practice
| will stay untarnished).
|
| Cryptography on the other hand is a well known example of
| something you should not touch at all unless you are an
| absolute expert- that's not even a "best practice" but
| probably the only reasonable practice.
| f1shy wrote:
| I could agree. It boils down to "you have to use your
| brain, and not try to invent and follow blind some rules"
| ohthatsnotright wrote:
| Often what is one developers "best practice" is another's
| "anti-pattern" because a lot of this is just arbitrary.
| pletnes wrote:
| Hot take, the biggest advantage to following <<best
| practices>> is that when someone else stumbles over your
| project, they can follow along more easily
| Angostura wrote:
| If it is arbitrary, it's "standard practice".
| lolinder wrote:
| Which still has immense value.
|
| It's standard practice to install outlets with NEMA
| connectors in North American buildings. Sure, you could
| technically swap those out with a more optimal connector
| that is "better" (one that prevents electricity from
| flowing while the plug is partially exposed, for example),
| but using the standard practice _is_ best practice for
| human-shaped reasons that are often not apparent to early-
| career engineers.
| dambi0 wrote:
| I'm a bit confused with the analogy here. Would the non
| NEMA outlets work with my existing things or is the
| implication that they wouldn't?
| pydry wrote:
| 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.
| ahoka wrote:
| There's usually nothing "best" about it.
| tajd wrote:
| 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.
| grifter wrote:
| The iThe
| davedx wrote:
| What if the "best practice" was invented by a VC funded company
| (like, just for example, Vercel) desperate to maintain their
| growth trajectory by any means necessary, including huge
| marketing pushes to convince everybody the "best practice" is
| the "best way to do things"?
|
| It's downright dangerous to assume a "best practice" in
| software development somehow automatically means it's some
| super distilled wisdom juice. A whole lot of it, in my
| experience, is just hype and rapid, unquestioning cargo culting
| slamming in right behind the hype.
|
| Use your fucking brain. If the "best practice" is objectively a
| good solution to your problem then use it. If not, think of
| something better.
| bayindirh wrote:
| I mean, consuming anything without vetting the source of the
| information is a bad practice in general.
|
| ...or,
|
| The best practice of best practices is vetting the source of
| the best practice to verify its authenticity.
|
| No?
| auggierose wrote:
| > Follow best practices unless you can give a reason not to.
|
| Cargo culting much?
|
| I'd say, follow best practices only if you can say exactly why
| it is best practice.
| bayindirh wrote:
| I don't think so. For example, If I'm writing something in a
| programming language I don't know by heart, I start by
| following the best practices recommended by the language
| authors, then start to flex them when they become less
| useful, until I hit a nice pitfall which these best practices
| are designed to avoid.
|
| This allows me to start faster, and be in a better shape in
| short term. Then I can flex advice more and more as I
| understand how a language works under the hood.
| auggierose wrote:
| I also read the language tutorial first. But if they don't
| explain their best practices (and often the explanation is
| simple), I don't care much for them.
| trm42 wrote:
| Best practices and such shouldn't be obeyed as "laws" but
| guidelines for general work. Once in a while there's good reason
| to avoid / skip them for whatever reason.
|
| The bigger issue is that developers (me included) are usually
| making the decisions in their own heads. Usually the reasons are
| quite ok but they are not really said out loud or documented.
|
| I've been stumbled upon this as both developer trying to get
| their code approved and when doing a code review.
|
| For the developer it feels super annoying that somebody nitpicks
| about things which the developer has probably gone through in
| their heads already and ended up with the resulting solution.
| Just like Martin in the post complains and reacts passive
| aggressively towards reviewers mentioning these things.
|
| For the code reviewer it feels like the developer is being sloppy
| or doesn't care about our common way of doing things thus
| increasing the need to nitpick and explain so that the developer
| understands how it should be done.
|
| The solution for this is actually quite easy: document in the
| comments and in the Pull Request _why_ you're breaking team's /
| company's guidelines and why you think it's warranted for
| solution for this case. This seems to remove quite a lot of
| friction.
|
| Oh and of course it doesn't mean that the guidelines should be
| broken all the time just because one thinks this kind of stuff is
| for "idiots|assholes". When working as a team, we need to adhere
| to common way of working for most of the time.
| heisenbit wrote:
| While I guess most would agree all the cited practices have been
| abused what is really the alternative? Absence of practices does
| not make things better - history has plenty lessons there. To run
| medium to large scale projects one needs patterns to ease
| communication and integration.
|
| The real question is how do we prevent best practices to be
| perverted and I fear the answer is having the right people in the
| right places. The one best practice to rule them all: Have
| knowledgeable balanced people who know when to break the rules.
| dkarl wrote:
| The alternative is to accept that every solution has drawbacks
| and trade-offs. Best practices were an attempt to codify design
| standards that would be equivalent to "buying IBM" in the sense
| of the old phrase, "Nobody gets fired for buying IBM."
|
| That was always a bad idea. Often the best choice in one
| context would be a bad choice in other contexts. You don't want
| an engineer in a 20-person startup making decisions like
| they're at Google, or vice-versa. You have to take
| responsibility for deciding what's best for a particular
| problem in a particular context, without looking for the cover
| of "everybody does it this way."
| jonathanlydall wrote:
| Perhaps it's due to the very large number of factors in a code
| base and/or the particular problem space.
|
| But as I got more senior, when asked by less experienced
| developers the best way to do something, my answers tended to
| increasingly start with: "Well, it depends...".
|
| And that's the thing, there is no universal best practice for
| everything, there are solutions which are more often than not
| good enough, but as all solutions tend to be a trade off
| favouring a particular scenario over another, sometimes they're
| also highly inappropriate to the particular circumstances.
|
| Another term for someone trying to blindly apply supposed best
| practices is "cargo culting".
|
| In summary, there is lot's nuance to software development and the
| particular circumstances it's being applied to meaning that you
| need to understand the trade offs of particular solutions to see
| which one makes the most sense for a particular situation.
| cadamsau wrote:
| There are 2 main kinds of advice that get labeled best practices
| in an attempt at persuasion:
|
| 1. Advice which worked in one situation - "we tried Agile,
| everyone should use it!"
|
| 2. Proven stuff like code review, which you call best practices
| when begging your org to implement it: "please let's do it, I can
| clearly see how this will improve our org."
|
| These 2 examples represent locations on a spectrum: let's call it
| "provenness".
|
| The author's problem boils down to subjectivity - everyone
| positions different practices in different places on the
| provenness axis. The upshot of that is when one person says "we
| should do this, it's obvious and/or it'll definitely help"
| another person hears "we tried it once, you should try it too!"
| and then everyone has a bad time.
|
| Then it gets confounded by everyone calling everything best
| practices - no matter how long ago or unproven the practices
| might be.
|
| What would be handy is some generally agreed-upon yardsticks for
| graduating practices into or out of best practices status, plus
| better terminology to cover the spectrum of provenness so more
| sophisticated discussions can be had that account for the nuance
| and we don't all talk past each other..
|
| But then analyst companies wouldn't get to make their glossy 2x2
| charts, so it probably won't happen.
| lijok wrote:
| Very handwavy. Just like the aforementioned zealots, idiots and
| assholes.
| TrianguloY wrote:
| "Don't do X" is bad. "Don't do X because it's not a best
| practice" is less bad, but still bad. "Don't do X because Y" is
| good.
|
| Only in the last one you can either understand the reason, or
| ignore the rule because it doesn't apply to your situation.
| cjfd wrote:
| The first paragraph of this is the truth. There is something
| wrong with people who enjoy telling other people what to do.
| elpocko wrote:
| >There is something wrong with people who enjoy telling other
| people what to do.
|
| Telling other people what to do is human's favorite thing. Give
| a man an opportunity to make and/or enforce rules, and you have
| a very happy man. People dedicate their whole lives to reaching
| stage after stage in their rule-making game.
| taeric wrote:
| 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.
| eapriv wrote:
| Software around us is quite terrible, so it's kind of obvious
| that one shouldn't follow "best practices" that led to this state
| of things.
| rileymat2 wrote:
| That implies they were created with best practices in the first
| place.
| resonious wrote:
| If not, then what _was_ created with best practices in the
| first place?
|
| If we can agree that most large, financially successful
| software projects are of questionable quality, then either
|
| - they used best practices and yet they still suck, OR
|
| - they did not use best practices, but are widely successful
| anyway.
|
| So no matter how you look at it, software best practices just
| haven't panned out.
| eapriv wrote:
| The name "best practices" kind of implies that they actually
| are practiced somewhere. So it's different from theoretical
| abstract ideas "how we should write software", which maybe
| nobody follows.
| NathanaelRea wrote:
| Maybe if people didn't follow best practices their software
| would be terrible-er? Guardrails for hard things doesn't imply
| no guardrails would make it easier.
| veltas wrote:
| "Postel's law" is an ironic name, I don't think the people who
| coined that term meant that it was an infallible rule of the
| universe, just what seemed a good rule of thumb for implementing
| protocols.
|
| I still like Postel's law, but don't imagine for a second it's a
| 'law' with the kind of authority the article implies, and didn't
| enjoy the article's slime about people who like it!
| tyleo wrote:
| Best practices are a way to avoid building everything up from
| first principles every time. They are more, "here are rules that
| are generally applicable so you don't have to waste time
| thinking," vs "here are laws of god which are always applicable."
|
| It is an error to throw out every best practice and reconsider
| everything just as it is to blindly follow the best practices.
|
| IMO it's best to apply the best practices by default and question
| them as they are used. Essentially trust but verify. Assuming
| they are right most of the time you get the benefit of speed.
| Assuming some of them are wrong, it still leaves room to course
| correct.
| HPsquared wrote:
| Maybe "good practice" is a better term.
| sbarre wrote:
| I've seen (and started using) "current common practices"
| instead of "best practices" where it makes sense.
|
| In an always-evolving technology landscape, it feels like a
| better representation of what we're doing, and it helps
| prevent the kind of dogmatic stubbornness that forms around
| the word "best".
| chthonicdaemon wrote:
| Rules travel further than reasons.
|
| The problem is that a lot of true things in the world are
| counter-intuitive. So insisting that all the rules "make sense"
| in an immediate way is clearly a non-starter. In the safety
| industry there are many examples of best practices that are bred
| from experience but end up being counter-intuitive to some. For
| instance, it might not make intuitive sense that a pilot who has
| gone through a take-off procedure thousands of times needs a
| checklist to remember all the steps, but we know that it actually
| helps.
|
| It's hard because there is usually some information loss in
| summarisation, but we also have limited memory, so we can't
| really expect people to remember every case study that led to the
| distilled advice.
|
| As a chemical engineer by training, though, I have constantly
| been amazed at how resistant software people are to the idea that
| their industry could benefit from the kind of standardisation
| that has improved my industry so much.
| burnt-resistor wrote:
| It will never happen outside of limited industries because it
| would appear to be a loss of "freedom". I think the current
| situation creates an illusory anarchist freedom of informality
| that leads to sometimes proprietary lock-in, vulnerabilities,
| bugs, incompatibility churn, poorly-prioritized feature
| development, and tyranny of chaos and tech debt.
|
| There are too many languages, too many tools, too many
| (conflicting) conventions (especially ones designed by
| committee), and too many options.
|
| Having systems, tools, and components that don't change often
| with respect to compatibility and are formally-verifiable far
| beyond the rigor of seL4 such that they are (basically) without
| (implementation) error would be valuable over having tools lack
| even basic testing or self-tests, lack digital signatures that
| would prove chain-of-custody, and being able to model and prove
| a program or library to a level such that its behavior can be
| completely checked far more deeply in "whitebox" and "blackbox"
| methods for correctness would prove that some code stand the
| test of time. By choosing lesser numbers of standard
| language(s), tool(s), and component(s) it makes it cheaper and
| easier to attempt to do such.
|
| Maybe in 100 years, out of necessity, there will be essentially
| 1 programming language that dominates all others (power law
| distribution) for humans, and it will be some sort of formal
| behavioral model specification language that an LLM will
| generate tests and machine code to implement, manage, and test
| against.
| BeFlatXIII wrote:
| I disagree slightly here. There may be one (1) dominant
| formal language that's used as the glue code that gets run on
| machines and verified, but it will have numerous font-end
| languages that compile into it, for ease of typing and
| abstraction/domain fit.
| michael1999 wrote:
| Who drove that standardization in chemical engineering?
|
| I ask, because the intra-organizational dynamics of software
| have been ugly for standardization. Vendor lock-in, submarine
| patents, embrace-and-extend, etc. have meant naive adoption of
| "best practices" meant a one-way ticket to an expensive,
| obsolete system, with an eventually insolvent vendor.
| agentultra wrote:
| 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.
| javcasas wrote:
| I'm one of the devs not aware of the SWEBOK. Searching the
| internet all I can find is links to "the guide to SWEBOK".
|
| https://ieeecs-media.computer.org/media/education/swebok/swe...
|
| But, you know, I want the whole ordeal. I want the SWEBOK, not
| the "how to read the SWEBOK". Where can I find it?
| desbo wrote:
| I think that is what you want. From Wikipedia:
|
| > In 2016, the IEEE Computer Society kicked off the SWEBOK
| Evolution effort to develop future iterations of the body of
| knowledge. The SWEBOK Evolution project resulted in the
| publication of SWEBOK Guide version 4 in October 2024.
|
| So the thing called "SWEBOK Guide" is actually the reference
| text for SWEBOK.
| GranPC wrote:
| It looks like SWEBOK Guide, guide to the SWEBOK, and SWEBOK
| are all used interchangeably. I wonder if they have a chapter
| on naming conventions.
| marcosdumay wrote:
| The books that encode some standardized Xbok are always named
| "The guide to the Xbok".
|
| The actual BOK isn't supposed to have a concrete
| representation. It's not supposed to be standardized either,
| but standard organizations always ignore that part.
| agentultra wrote:
| This. They're supposed to represent the _state of the art_
| which is constantly evolving.
| marcosdumay wrote:
| Well, literally the "state" as in what is the knowledge
| that everybody shares. We usually call that by something
| closer to "minimum common denominator".
|
| What people usually call "state of the art" is the best
| knowledge that is reasonably well known. That is out of
| scope. If you take a look on this one, it's full of stuff
| that we knew not to use on the 20th century. This is
| typical.
| rfrey wrote:
| The confusion is because "BOK" is not "book of knowledge" but
| "body of knowledge". So a "guide" as a canonical source kinda
| makes sense.
| TehShrike wrote:
| I think it is best to strongly reject the idea "best practices
| will always benefit you".
|
| Most best practices that I have been told about were low local
| maxima at best, and very harmful at worst.
|
| If someone quotes a best practice to you and can't cite a
| convincing "why", you should immediately reject it.
|
| It might still be a good idea, but you shouldn't seriously
| consider it until you hear an actually convincing reason (not a
| "just so" explanation that skips several steps).
| 0xbadcafebee wrote:
| I don't think anyone has ever thought that best practices
| will _always_ benefit you. Nothing always works every single
| time in every single case.
|
| This whole thing is really silly and obvious.
|
| Of course you shouldn't blindly follow advice without
| thinking. But not following advice just because it might not
| always be right is also a bad idea.
|
| My advice: _In general_ , you should follow _good advice_
| from _experienced people_. If _enough experts_ say this is
| the best way to do something, you should _probably_ do that,
| _most_ of the time.
|
| But that advice will never trend on HN because it isn't
| clickbait or extreme, and requires using your noggin.
| TehShrike wrote:
| > I don't think anyone has ever thought that best practices
| will always benefit you.
|
| Whenever a "best practice" or "convention" has been
| presented to me, that is how it has been framed. (...it is
| best practice, therefore, it will definitely benefit you to
| follow it)
| davorak wrote:
| I do not know what context this happened to you in, but
| in the context of building something quickly, learning,
| while not being an expert in an area, best practice are a
| common crutch.
|
| In many work places either they do not have time or at
| least think they do have time to think things through
| 100% for themselves from first principles so they depend
| on best practices instead.
|
| That makes sense to me and I would expect better results
| on average with using best practices than rejection of
| best practices in the above context.
|
| That said I try to work on things where I am not always
| in the above context, where thinking things through end
| to end provides a competitive advantage.
| agentultra wrote:
| 100%... a best practice in other traditional engineering
| practices help us work within the state of the art.
| They're the accumulated wisdom and experience of
| engineers that came before us.
|
| There are plenty of them that help us write concurrent
| code that avoids common deadlock situations without
| having to resort to writing proofs every time. Someone
| already did the work and condensed it down into a rule to
| follow. Even if you don't understand the underlying proof
| you can follow the rule and hope that everything will
| shake out.
|
| What I find we struggle most with is knowing when we
| actually need to write the proof. Sometimes we bias
| ourselves towards best practices and intuition when
| working it out formally would be more prudent.
| KronisLV wrote:
| > Most best practices that I have been told about were low
| local maxima at best, and very harmful at worst.
|
| This matches my experience, though sometimes they indeed will
| be helpful, at least after some consideration.
|
| > If someone quotes a best practice to you and can't cite a
| convincing "why", you should immediately reject it.
|
| In certain environments this will get you labeled someone who
| doesn't want to create quality software, because _obviously_
| best practices will lead to good code and not wanting to
| follow those practices or questioning them means that you don
| 't have enough experience or something. Ergo, you should just
| apply SOLID and DRY everywhere, even if it becomes more or
| less a cargo cult. Not that I agree with the idea, but that
| way of thinking is prevalent.
|
| (not that I agree with that, people just have that mindset
| sometimes)
| layer8 wrote:
| While I like the idea of SWEBOK, the actual SWEBOK book is not
| very useful though, quite incomplete, biased, and not up to
| date.
|
| There was recently a HN thread about it:
| https://news.ycombinator.com/item?id=41907412
| ozim wrote:
| * _However they shouldn't be rejected out of hand either and
| people recommending them aren't idiots.*_
|
| Also it shouldn't be taken for granted that best practice is
| always "best/good" - there definitely are idiots recommending
| best practices.
| michael1999 wrote:
| I like SWEBOK, but I don't understand your point.
|
| SWEBOK seems the opposite of that. A body of knowledge is not
| at all the same thing as a best practice. The only unapologetic
| best practice in SWEBOK is that professionals should be
| familiar with every topic in SWEBOK. Definitely not that you
| _should_ do everything in the book.
|
| The book is quite sophisticated in this. It explicitly separate
| the technical knowledge from the judgments of which, when, and
| where to apply it. Most occurrences of "best practices" in the
| text are quoted, and are references to other works and describe
| the need to choose between different best-practice libraries
| depending on context. Others are part of a meta-conversation
| about the role of standards in engineering. Very little of
| SWEBOK is promoted as a "best practice" in itself.
|
| Here's a quote from SWEBOK v4, 12-5
|
| > Foremost, software engineers should know the key software
| engineering standards that apply to their specific industry. As
| Iberle discussed [19], the practices software engineers use
| vary greatly depending on the industry, business model and
| organizational culture where they work.
| agentultra wrote:
| > I don't understand your point
|
| In my view best practices emerge from a body of knowledge (or
| sometimes from the practice and wisdom of others that haven't
| been documented/accepted/etc yet) and are "shortcuts."
|
| I'm not defending Postel's Law; I agree that, after years of
| practice and research, it leads to security issues and
| surprises.
|
| However, the point is that these kinds of principles don't
| arise out of people's heads and become accepted wisdom for
| nothing; they're usually built off of an implied (or
| explicit) body of knowledge.
|
| Does that make sense?
| SoftTalker wrote:
| 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.
| jrs235 wrote:
| 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... )
| revskill wrote:
| It is artificial standards for review. You can break it, but do
| it if u can.
| cromulent wrote:
| I hear the phrase "best practices" not from the best
| practitioners, but from Dunning-Kruger types.
|
| Recently I was told that Hungarian notation was "best practice"
| and I must use it.
| gspencley wrote:
| > but because they're mostly pounded by either 1) various types
| of zealots, idiots, and assholes who abuse these kind of "best
| practices" as an argument from authority, or 2) inexperienced
| programmers who lack the ability to judge the applicability,
|
| The author might go on to make other points that are worth
| discussing, but lays out his supporting arguments clearly in the
| opening paragraph. Best practices do not necessarily do harm
| because they offer bad advice, they do harm because they are
| advocated for by zealots and the inexperienced.
|
| My first reaction is how unfortunate it is that this particular
| developer has found himself in the presence of bad engineers and
| the inexperienced.
|
| But then, the argument is automatically self-defeating. Why is
| the rest of the article even worth reading, if he states upfront
| what his arguments are and those arguments are very easy to
| refute?
|
| It is deeply irrational to judge the merits of an idea based
| solely on who is advocating for that idea.
|
| My advice to the author is to reflect on the types of positions
| that he accepts, the ones that have him so put off by the people
| that he works with that he is openly writing about abandoning
| what he admits could be sound engineering practice, solely based
| on who that advice is coming from and how it is being delivered.
|
| Developing software is complicated. It is constant problem
| solving. When solutions to problems come about, and we abstract
| those solutions, it is quite easy for individuals to misapply the
| abstraction to an inappropriate concrete. To drop context and try
| to retrofit a lousy solution because that solution was
| appropriate to a slightly different problem. But at the end of
| the day, these abstractions exist to try and simplify the
| process. Any time you see a "best practice" or design pattern
| acting as a complicating force, it is not doing its job. At that
| point you can either be objective and exercise some professional
| curiosity in order to try and understand why the solution adopted
| is inappropriate ... or you can take the lazy way out and just
| assume that "best practices" are the opinions of zealots and the
| inexperienced who blindly follow because they don't know any
| better.
| convolvatron wrote:
| we don't have to give undue value to 'best practices', nor do
| we need to judge an idea based on its presenter. we just need
| to have a reasonable discussion about the idea in the context
| in which its being applied. this simple approach has been
| largely eclipsed in the industry by the fetishization tools,
| and the absurd notion that whole classes of approaches can be
| dismissed as being 'antipattern'.
|
| It's not very hard to weigh a suggestion. speculate about its
| costs, benefits and risks.
| hinkley wrote:
| Some of those fetishized tools are themselves anti patterns.
| danenania wrote:
| > Best practices do not necessarily do harm because they offer
| bad advice, they do harm because they are advocated for by
| zealots and the inexperienced.
|
| I think the point is that blindly suggesting "best practices"
| often _is_ bad advice.
|
| It's a common form of bikeshedding--it allows someone to give
| their casual two cents without doing the hard work of thinking
| through the tradeoffs.
| cpill wrote:
| I think the problem is that a lot of computer nerds are a bit
| OCD and like to apply one solution to everything. You see this
| with how they get crazy about strictly typed versus not
| strictly typed, one particular language for every application,
| or spaces vs tabs. I was like that when I was younger but as I
| get older I realized the world is the complex place and has
| programs have to deal with the real world there is no one
| solution fits all, or a best practice that always applies. To
| become good at programming you need to be adaptable to the
| problem space. Best practices are great for juniors once you've
| got a bit of experience you should use that instead.
| isk517 wrote:
| My job revolves around adopting software solutions to solve
| practical problems and let me tell you, this mentality of one
| solution to everything goes beyond just the coding. I've
| encountered countless developers that seems to believe that
| the reality of a business should conform itself to how the
| developer believes your business/industry should operate.
| pizlonator wrote:
| Someone once told me something like, "rules work best when human
| judgement is used when applying them".
|
| I think that's what this article is basically saying. And I
| agree.
| satisfice wrote:
| "Best practices" have nothing to do with engineering. They are a
| marketing concept. They are a kind marketing better known as
| bullying.
|
| In every case where you want to say "best practice" there is a
| better alternative, which is to say "practice." The concept of
| best is never needed or warranted, because practices are not
| subject to rigorous testing and review.
|
| I have been an independent consultant and trainer since 1999 and
| not once have I taught or recommended a best practice.
|
| I do have many opinions. I call them: opinions. I think my
| opinions are the best, but I can't think of any reason that
| anyone else beyond my wife and dog should think so.
| binary132 wrote:
| I can sense the hackles rising. The arcane magi of the Guidance
| Council have scried a rebel wizard in their orb. Every cantrip
| and charm must be uttered at once, with maximal urgency! Invoke
| the spirits of the tomes!!!
| jsbg wrote:
| The author sounds like even though they have read extensively
| about various "best" practices, they did not really gain an
| understanding of the tradeoffs involved with each one.
|
| > "Don't Repeat Yourself" (DRY) is basically good advice, but
| sometimes just copy/pasting things is just the more pragmatic
| thing to do, and not really a big deal.
|
| Duplicating code on purpose is not about being pragmatic, it's
| about recognizing when DRY would violate the single
| responsibility principle.
|
| The ability to weigh tradeoffs in context is what makes some
| engineers better than others.
| layer8 wrote:
| The problem with DRY is that it is expressed incorrectly and
| misleadingly. There is little _inherent_ benefit in avoiding
| code duplication, and it can do harm when done for the wrong
| reasons. The actual context is change management. Will the copy
| of the code likely have to change in the same way as the
| original? Only then should duplication be avoided. The rule
| taken literally fails to convey this important precondition and
| the reasoning behind it. (And so does WET.)
| recursive wrote:
| > The author sounds like even though they have read extensively
| about various "best" practices, they did not really gain an
| understanding of the tradeoffs involved with each one.
|
| It sounds to me like they _did_ understand the tradeoffs. But
| that they were being brow-beaten to apply "best practices"
| that were inapplicable _because_ of the tradeoffs.
| lkrubner wrote:
| Dan Morena, CTO at Upright.com, made the point that every startup
| was unique and therefore every startup had to find out what was
| best for it, while ignoring whatever was considered "best
| practice." I wrote what he told me here:
|
| https://respectfulleadership.substack.com/p/dan-morena-is-a-...
|
| My summary of his idea:
|
| No army has ever conquered a country. An army conquers this muddy
| ditch over here, that open wheat field over there and then the
| adjoining farm buildings. It conquers that copse of lush oak
| trees next to the large outcropping of granite rocks. An army
| seizes that grassy hill top, it digs in on the west side of this
| particular fast flowing river, it gains control over the 12 story
| gray and red brick downtown office building, fighting room to
| room. If you are watching from a great distance, you might think
| that an army has conquered a country, but if you listen to the
| people who are involved in the struggle, then you are aware how
| much "a country" is an abstraction. The real work is made up of
| specifics: buildings, roads, trees, ditches, rivers, bushes,
| rocks, fields, houses. When a person talks in abstractions, it
| only shows how little they know. The people who have meaningful
| information talk about specifics.
|
| Likewise, no one builds a startup. Instead, you build your
| startup, and your startup is completely unique, and possesses
| features that no other startup will ever have. Your success will
| depend on adapting to those attributes that make it unique.
| alach11 wrote:
| Wow what a fantastic little article. Thanks for writing and
| sharing that.
| gbacon wrote:
| Likewise, people do business with people, not with companies.
| Assert that "society" is merely an abstraction invoked for
| political gain to become an individualist.
| cafard wrote:
| Seriously? From whom do I buy a computer or a car or a
| refrigertor?
| KineticLensman wrote:
| > people do business with people, not with companies
|
| Many of my interactions are with electronic systems deployed
| by companies or the state. It's rare that I deal with an
| actual person a lot of the time (which is sad, but that's
| another story).
| coding123 wrote:
| The army that is conquering is carrying best practice weapons,
| wearing best practice boots, best practice fatigues, best
| practice tanks, trucks, etc.
|
| They're best practice aiming, shooting, walking, communicating,
| hiring (mercs), hiding, etc...
|
| The people that are in the weeds are just doing the most simple
| things for their personal situation as they're taking over that
| granite rock or "copse of lush oak trees".
|
| It's easy to use a lot of words to pretend your point has
| meaning, but often, like KH - it doesn't.
| godelski wrote:
| This is frequently not true. There's examples all through
| history of weaker and poorer armies defeating larger ones.
| From Zulus, to the American Revolution, to the great Emu
| wars. Surely the birds were not more advanced than men armed
| with machine guns. But it's only when the smaller forces can
| take advantage and leverage what they have better than
| others. It's best practices, but what's best is not
| universal, it's best for who, best for when, best for under
| what circumstances
| coding123 wrote:
| That doesn't defeat my point- is the smaller/poorer army
| using best practices?
|
| When all things are the same, the army with more will win.
|
| When all things are not the same, there are little bonuses
| that can cause the smaller/poorer, malnourished army to win
| against those with machine guns. Often it's just knowing
| the territory. Again though, these people are individually
| making decisions. There isn't some massively smart borg
| ball sending individual orders to shoot 3 inches to the
| left to each drone.
| godelski wrote:
| > That doesn't defeat my point- is the smaller/poorer
| army using best practices?
|
| I don't agree, but neither do I disagree. But I do think
| it is ambiguous enough that it is not using best
| practices to illustrate the point you intend.
| > malnourished army to win against those with machine
| guns
|
| With my example I meant _literal_ birds
|
| https://en.wikipedia.org/wiki/Emu_War
| cafard wrote:
| The Zulus won a pitched battle or two, but lost the war.
| adamc wrote:
| Often not true. Often they are just "good enough" weapons,
| etc.
| godelski wrote:
| > No army has ever conquered a country
|
| Napoleon and his army would like to have a word with you...
|
| I get the analogy but I think it can be made a lot better,
| which will decrease people who dismiss it because they got lost
| in where the wording doesn't make sense. I'm pretty confident
| most would agree that country A conquered country B if country
| B was nothing but fire and rubble. It's pretty common usage
| actually. Also, there's plenty of examples of countries ruled
| by militaries. Even the US president is the head of the
| military. As for army, it's fairly synonymous with military,
| only really diverting in recent usage.
|
| Besides that, the Army Corp of engineers is well known to build
| bridges, roads, housing, and all sorts of things. But on the
| topic of corp, that's part of the hierarchy. For yours a
| battalion, regiment, company, or platoon may work much better.
| A platoon or squad might take control of a building. A company
| might control a hill or river. But it takes a whole army to
| conquer a country because it is all these groups working
| together, even if often disconnected and not in unison, even
| with infighting and internal conflicts, they rally around the
| same end goals.
|
| By I'm also not sure this fully aligns with what you say. It's
| true that the naive only talk at abstract levels, but it's
| common for experts too. But experts almost always leak
| specifics in because the abstraction is derived from a nuanced
| understanding. But we need to talk in both abstractions and in
| details. The necessity for abstraction only grows, but so does
| the whole pie.
|
| https://en.wikipedia.org/wiki/Military_organization
| c22 wrote:
| The US president, a civilian, is in command of the US
| military. This is, in fact, the inverse of a country being
| run by its military.
| KineticLensman wrote:
| Also true in the UK. Even in a war the UK armed forces are
| ultimately tasked by and report to politicians.
| graemep wrote:
| Its true everywhere except for military dictatorships.
| eichi wrote:
| I want engineers to think about the best for the project but I
| let engineers talk about the best of implementation because it's
| better than doing irrevant things.
| dkarl wrote:
| Living through the 2000s was enough to give me a permanent
| aversion to "best practices." So many things that we look back on
| in horror were smugly and haughtily justified using those words.
|
| There was a culture of best practices zealots that had an uncanny
| resemblance to organized religion. All the answers have been
| written down for us, and everything that goes wrong is because of
| arrogant, misguided people who decided to trust their own
| fallible thoughts instead. Their faith was strong enough to
| survive any project, no matter the outcome.
| betenoire wrote:
| Only software engineers pretend best practices exist outside of
| any useful context.
|
| - small localized team vs big distributed team
|
| - bug fixes and incremental improvements vs green field poc
|
| - saas vs system scripts
|
| Context matters, and if people aren't giving you the context in
| which they deem practices to be "best", they are myopically wrong
| davorak wrote:
| So outside of coworkers that have a hard time collaborating in
| general, is it a problem for others that their coworkers will
| not apply context? That has not been my experience.
| betenoire wrote:
| I don't understand the question... If someone has a strong
| opinion, and they have arguments for their opinion, but don't
| recognize the significance of the context in which they've
| formed their opinions, they have blind spots they aren't
| aware of. Is that a problem? I dunno, that's up to you and
| your environment.
| uludag wrote:
| > "Don't use globals" is obviously good, but "never use globals
| under any circumstances" is just silly
|
| I'm actually not even convinced that this is a good rule. When
| it's explained it makes sense on the surface. I also think that
| since beginners to programming use global variables, they come to
| the conclusion that it must be universally bad since that's what
| their beginner self did.
|
| Having work on codebases with most state being being stored as
| global variables (in a single namespace at that) is manageable at
| worst and easy to develop on at best, assuming certain
| conventions are followed.
| kthejoker2 wrote:
| IME "best practices" is a demand problem, not a supply problem.
| IE far more people _want_ best practices than there are actual
| best practices.
|
| Prospects and customers desperately want to know our "best
| practices" and then complain when we say "it depends" or
| something experimentation is required, as if we are hiding secret
| teachings from them.
|
| For me this is more a personality test: people who just want
| solutions on a silver platter vs DIYers who want to tinker and
| distrust black boxes.
| bobbruno wrote:
| That's an interesting point, which leads me to my main reason
| for coming to these comments and leaving my 2 cents: there are
| way less best practices of there than one would believe by
| looking at all the places, people and firms offering some set
| of "best practices".
|
| One thing I learned after many years working in consulting is
| that, more often than one would believe, best practices are
| just a compilation of whatever could be found (hopefully at
| least common practices, more often "things I could find that
| were minimally documented to be reusable"), with no serious
| analysis of their claim of superiority other than them being
| common.
|
| So, first thing: learn to challenge the claim of "best". Best
| for whom? Under what context? What other not-so-good practices
| are out there, and why is this the best?
|
| Second:if it's documented and evident enough to be treated as a
| best practice, it's probably fairly common knowledge already.
| Barring the commonality of really bad things being done out
| there, don't expect that you'll become much more than mediocre
| by adopting best practices. By the time they get to be called
| there, they are no longer any competitive advantage, more a
| basic thing you should be doing already - assuming they are
| indeed best practices (as per my previous point).
|
| It's not that I'm against best practices as a concept, or
| compiled bodies of knowledge. Just don't expect them to do more
| than keep you somewhere in the middle. True leadership and
| innovation lies where best practices have not been established
| yet - together with all the dangers and mistakes you can make
| on uncharted waters.
| dblohm7 wrote:
| The real problem is dogma and cargo culting.
| antirez wrote:
| I agree with the sentiment of the article, but Postel law is a
| good idea that has very little to do with the context. Of course
| the real problem is that it's a very small advice that needs to
| be put into context each time, and here is the failure of all the
| types of advices: they are not substitutes for intelligence and
| good design tastes.
| layer8 wrote:
| The advantage of best practices is that you have something you
| can follow without having to analyze the situation in depth. The
| disadvantage of best practices is that you may have to analyze
| the situation in depth to notice that they maybe aren't the best
| choice in the specific situation. The harm that best practices
| can do are lessened by viewing them as a rule of thumb
| conditioned on certain premises rather than as a dogma.
| nativeit wrote:
| "Dogma" is the key word in this situation, I believe (and in a
| lot of similar situations). There are very few examples for
| when dogmatic obedience is healthy, helpful, or appropriate.
| Sadly, the trends seem to be heading the wrong way, with more
| tribalism than pragmatism.
| safetytrick wrote:
| I'm proud of my little joke on dogmas: "The only dogma I
| believe is that all dogmas are wrong".
| malfist wrote:
| I like to use the term "golden path" instead of best practices.
|
| In a golden path, lots of others have gone before you and
| figured out all the nuance. But this doesn't mean the path is
| the best one for you, but does mean you should have a good
| reason for starying from it
| hinkley wrote:
| To which they will respond with something from their VC deck,
| like, "because we're Uber for <whatever>"
|
| Buddy that's not a reason, that's a rationalization.
| baxtr wrote:
| That's why I think Best Practice is a bad term. I rather call
| it something like Best Toolkit or Best Elements.
| eterm wrote:
| Following "Best practice" isn't about doing what is "best", it's
| about being predictable.
|
| In many cases, being predictable is better for future maintenance
| than forging your own path, even if the custom solution is
| "better" against all (current) metrics.
| MantisShrimp90 wrote:
| The longer I program the more I agree with this take. I have seen
| too much power and dominance from people who wield it as a cudgel
| against everyone else in the room who doesn't care enough to
| double-check the practice.
|
| Put another way, knowledge is knowing best-practices, but wisdom
| is knowing where and when to apply them. Unfortunately, most
| building software have only the knowledge and there is too little
| consideration for the fact that structure is not free, and
| considerations must be made for when velocity is the primary
| objective vs safety and adherence to best-practices.
|
| It all comes down to architecture design in the end.
| js2 wrote:
| Ralph Waldo Emerson: "A foolish consistency is the hobgoblin of
| little minds, adored by little statesmen and philosophers and
| divines. With consistency a great soul has simply nothing to do.
| He may as well concern himself with his shadow on the wall. Speak
| what you think now in hard words, and to-morrow speak what to-
| morrow thinks in hard words again, though it contradict every
| thing you said to-day. -- 'Ah, so you shall be sure to be
| misunderstood.' -- Is it so bad, then, to be misunderstood?
| Pythagoras was misunderstood, and Socrates, and Jesus, and
| Luther, and Copernicus, and Galileo, and Newton, and every pure
| and wise spirit that ever took flesh. To be great is to be
| misunderstood."
|
| https://en.wikipedia.org/wiki/Wikipedia:Emerson_and_Wilde_on...
|
| (This is relevant to the extent that programming is as much art
| as science/engineering.)
| ssrc wrote:
| Like any other discussion of this kind[1] I think this one will
| go nowhere because 1) the question doesn't have a black and white
| answer, it's a sliding scale. 2) almost no one is giving examples
| of what they mean; if they were, they could find that they agree
| with the person they are replying to. And 3) most people will
| discard the experiences of people they disagree with "you didn't
| even try! maybe the problem is you!", and this is easy because
| this is the internet and the other person can be (is probably?)
| making it up.
|
| [1]https://www.joelonsoftware.com/2009/09/23/the-duct-tape-
| prog...
| bongodongobob wrote:
| Ragebait post unless you enjoy playing semantics games with
| verysmarts. If you don't understand the purpose of the term "best
| practices", they were probably made for someone like you.
| recursive wrote:
| The problem is when one _does_ understand, but is being
| subjected to them by someone who doesn 't.
| worik wrote:
| No.
|
| I've worked too often with people who think they know better
|
| They do not
|
| Straw men do not change the fact that "best practices" ,
| especially the ones quoted, are very good.
|
| No sensible person is saying "never use globals". We caution you
| to think very carefully before you do, only for truly global
| state.
|
| I am suffering from inherited code, written by a very good
| programmer, who got lazy with globals and comments. Too many of
| the former, too few of the later. What a nightmare
|
| This article is arrant nonsense
| recursive wrote:
| > No sensible person is saying "never use globals".
|
| Maybe so, but still, plenty of people are saying it.
| syngrog66 wrote:
| yikes
| srmatto wrote:
| The author sort of goes against his own advice but not diving
| into the specifics of why he doesn't like certain things. I get
| that such a piece would be longer, take more time and effort, and
| would draw more argumentation but that's what he's asking for in
| the piece itself.
| mediumsmart wrote:
| Best Practice is to not care about the stupid asshole who came up
| with a brilliant method that works.
|
| _I tried to have the grammar checked by chatgpt but it was too
| challenging_
| graypegg wrote:
| I have an on-going topic with friends at work about what
| accessibility "means".
|
| It annoys me to no end when devs talk about some specific
| technical change "increasing accessibility". The accessibility
| best practices are used as a checklist where more checks = more
| accessibility points = better. It results in people gaming the
| score with meaningless repetitive metadata or low-impact tweaks,
| rather than actually improving the
| descriptive/alternative/touch/visual interface. Usually never
| even trying any alternative method of interacting with an
| interface.
|
| The best practice is "always include metadata", but it leaves off
| "... that adds context about the element rather than noise, and
| integrates with a surrounding application that uses consistent
| metadata labelling. Remember, this is a portion of a complete
| descriptive interface someone has to use."
|
| These best practices being driven into people's brains verbatim
| means conversations devolve into inane on-or-off taxonomy
| discussions like "is this colour accessible?" or "have we added
| accessibility? Do you need a ticket for that?" where pushing back
| isn't seen as caring about users, it's seen as being "against
| accessibility".
|
| https://graypegg.com/2023/11/25/the-private-definition-of-ac...
| munificent wrote:
| It took me way too long to realize this, but my experience is
| that "zealots, idiots, and assholes" (as the author says) are
| going to abuse _something_ and wield it as a bludgeon against
| other people. This appears to be a fixed, immutable property of
| the universe.
|
| If you take it as a given that some number of people are going to
| get an idea lodged in their head, treat it like gospel, and beat
| as many other people in the head with it as they can... the best
| strategy you can adopt is to have the ideas in their head be at
| least _somewhat_ useful.
|
| Yes, reasonable people understand that "best practices" come with
| all sorts of context and caveats that need to be taken into
| account. But you won't always be dealing with reasonable people,
| and if you're dealing with an asshole, zealot, or idiot, I'd sure
| as hell prefer one who blindly believes in, say, test-first
| development versus believing that "test code isn't real code, you
| should spend all of your time writing code that ships to users"
| or some other _even worse_ nonsense.
| safetytrick wrote:
| I like to phrase this kind of thought as: "The only dogma I
| believe, is that all dogmas are wrong".
| miguelbemartin wrote:
| "Best practices" is a tool that you need to know how to use it.
| Same as any other tool. If you do use the same tool for
| everything, this is when a tool becomes a bad thing.
|
| "Best practices" is a really good tool if you use it in the
| correct context.
| miguelbemartin wrote:
| "Because it's best practices" can not be used as an argument.
___________________________________________________________________
(page generated 2024-11-18 23:00 UTC)