Live data from Hacker News

Against Best Practices

arp242.net

181–190 of 218 posts

Re: Against Best Practices

#181

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

Wow what a fantastic little article. Thanks for writing and sharing that.

my irony detector is going off, but it's feeble. do I need a better irony detector?

Re: Against Best Practices

#182

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

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.

Makes me think as well of the best practices in development & project management methodologies.

Re: Against Best Practices

#183
So we shouldn't:

- Use source control?

- Have build automation?

- (at least some) automated testing?

- Protect data structures accessed concurrently with a mutex?

- Have backups?

I wouldn't say there isn't some imaginary situation where you'd do something different, but it's safer to fall back to doing the above in most situations.

That said many people make up "best practices" or use them without understanding the circumstances to which they apply.

Re: Against Best Practices

#184

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…

In any given culture (software development) you will have a set of traditions that may be used by the members of that culture to signify status, experience, pedigree and authority, and often some combination of all these and other descriptors. And, by virtue of creating a culture, you will also necessarily create a counter-culture, which rejects those things (performatively or otherwise) in an effort to do the exact same thing, but in the other direction. If you decide that proper software is developed with command-line in mind first, and UI second, you will in that effort necessarily create software devs who believe the exact opposite. This is core to our being as humans.

In my mind, this author is merely signaling software counter-culture, some of which I agree with, others I don't. And the people whom you describe above are signaling software culture, in a hostile and domineering way.

And of course, these two sides are not impermeable, forever persistent: culture and counter-culture shift constantly, often outright reversing from one another on a roughly 30 year timeline. And, they both have important things to offer. Best practices are best practices for a reason, and also telling stuffy people to chill out when they're focused so hard on best practices that they lose the plot of what the org is actually attempting to accomplish is also important.

Re: Against Best Practices

#185

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

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

So.. how would you make it a lot better?

Re: Against Best Practices

#186

Earlier quoted context omitted.

> 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.

I'd say Yes and No, there are standardized ways to analyze common engineering problems, for example beam deflection equations https://en.wikipedia.org/wiki/Deflection_(engineering) or Heat Exchanger efficiency calculations ( https://en.wikipedia.org/wiki/Logarithmic_mean_temperature_d... ) etc. Often the models and equations rely on making assumptions in order to simplify the problem (cue the joke about physicist and…

I'm not sure that's analogous to "best practices" like "do not repeat yourself (DRY)" or "don't use GOTO". These are little more than stylistic choices that claim to offer more maintainable code. Comparable "best practices" in other engineering fields would be along the lines of "do not chamfer/fillet until the end of modelling" (one I have heard before).

Analyzing a CAD model as you describe is more like running a compiler or type checker on code already written, which is the norm in software too, but is not within in the vein of the topic of discussion.

Re: Against Best Practices

#187

Earlier quoted context omitted.

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…

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

Occasionally something novel and innovative beats the best practice. In that case it usually gradually gets adopted as best practice. More often it doesn't, and falls by the wayside.

Re: Against Best Practices

#188
most "best practices" are just trends that got way out of hand. Microservices, long variable names, XML, TDD, SCRUM, OOP were just marketing concepts that turned into a cult.

Books like Code Complete are useful tools but not bibles.

Just like everything on the internet: it's just another person's opinion. What matters is what works (i.e. makes you money).

Re: Against Best Practices

#189

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

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…

> 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).

If everyone follows that then every decision will be bikeshedded to death. I think part of the point of the concept of "best practices" is that some ideas should be at least somewhat entrenched, followed by default, and not overturned without good reason.

Ideally your records of best practices would include a rationale and scope for when they should be reexamined. But trying to reason everything out from first principles doesn't work great either.

Re: Against Best Practices

#190
I think the problem is that the definition of "best practices" is a little muddy.

for example:

- use source control

- don't put spaces in file names

- camelcase is better than underscores in variables

- vi not emacs

some are really best practices, some are controversial choices someone is pushing.

Some places I've worked with good policies deliberately left some open. And made choices earlier on troublesome ones like spaces not tabs.

I think the choosing or defining vs not choosing is what companies should do to define themselves.

Post reply on HN