Are software engineering “best practices” just developer preferences? • Hacker News Board

Re: Are software engineering “best practices” just developer preferences?

#351

Post by diroussel » Fri, Oct 01, 2021, 5:54 PM UTC

BeFlatXIII wrote: post #348

atoav wrote: post #326

Earlier quoted context omitted.

I am not sure if I read you right here (correct me if I am wrong), but do you say that safety and stability concerns lead to bloated software because devs cannot blindly trust third party dependecies? Because if so, yeah. You are responsible for the software you write and the dependecies you use. Software engineering is one of the least responsible engineering diciplines anyways. I am e.g. also a certified electrical…

IMO, much of the low engineering standards in software is from a (potentially false) awareness in the industry that most products we work on simply aren't that valuable. If a bug deletes my Twitter account, that sucks to me be for a day but no real harm was done. The people who work in banking or healthcare IT tend to know better and have correspondingly higher (though still shockingly low) standards.

Haha. The banks ought to know better, but in fact due to software being hard to prove correct, we still get major disasters like the TSB migration failure. It caused real world problems like peoples house purchase deals falling through and money getting lost:

https://www.theguardian.com/business/2018/jun/06/timeline-of...

The thing, is there is seemingly no appetite to try to prove correctness of even single machines systems. Let alone distributed systems. I wonder if ever there will be a time where this kind of proof is cheap enough to be acceptable to business.

Re: Are software engineering “best practices” just developer preferences?

#352

Post by chmsky00 » Fri, Oct 01, 2021, 7:17 PM UTC

Dudeman112 wrote: post #334

chmsky00 wrote: post #289

Earlier quoted context omitted.

“Best practices” smells like such a marketing term it should be tossed in the bin. It’s poetic language that has nothing to do with specific problems. What people usually mean when it comes to engineering is “be safe, reliable, and correct.” Security best practices to be safe. Developer best practices for reliability. Etc etc “Best practices” is hand wave-y fluff for “do a good job” and doesn’t need a technical defin…

I think it's very telling just how little engineering there is in Software Engineering that people can call best practices "just preferences" or "marketing fluff" and not be immediately laughed out of the room. Because that's what would happen if someone suggested "best practices smells like a marketing term" in an actual engineering discipline.

Engineer to solve the problem. Not banter online.

My problem is people take a slogan like best practices and copy-paste in every new framework because it’s de facto best practice.

If the business is one of 1,000 todo apps, sure copy paste.

But it’s new hardware best practices are different and we ought to acknowledge that software use case isn’t as uniform as electronics, where Ohms law and material waste are coupled to waste.

Language choice and syntax choice depends on the problem as the team sees it. Avoid buffer overruns, sanitize inputs.

There you have it; software best practices.

Re: Are software engineering “best practices” just developer preferences?

#353

Post by zerd » Fri, Oct 01, 2021, 7:46 PM UTC

BiteCode_dev wrote: post #8

rajin444 wrote: post #5

Earlier quoted context omitted.

To make the comparison fair, in that world civil engineers would also have the ability to change the laws of physics.

And the bridge collapsing would usually not kill people but strip all their clothes. Also you can start a bridge in your garage.

If only building a bridge in your garage could make you a billionaire. People would build bridges like crazy.

Re: Are software engineering “best practices” just developer preferences?

#354

Post by sagichmal » Fri, Oct 01, 2021, 8:07 PM UTC

ori_b wrote: post #252

sagichmal wrote: post #248

Earlier quoted context omitted.

Each of these things prevents isolated testing of dependent components. For that reason alone they are nonstarters.

globalvar = new NopImpl() works fine for testing. If you squint, you can even think of dependency injection frameworks like Dagger as a lot of boilerplate around a global database of instantiations.

As dcow pointed out, it really doesn't work fine for testing, as it couples what should be isolated tests together, and prevents them from being executed concurrently.

Re: Are software engineering “best practices” just developer preferences?

#355

Post by sagichmal » Fri, Oct 01, 2021, 8:09 PM UTC

dcow wrote: post #290

sagichmal wrote: post #249

Earlier quoted context omitted.

Singletons are globals, aren't they?

Kinda depends. Single instance things are usually globally referenced, but as long as you're referencing an instance and not a static thing they're not hard to convert to an "injected" dependency if you need to provide a test impl to some thing being tested. The real problem is static things that can't be swapped out because you're actually calling static methods on some class rather than sharing an instance and call…

I understand "singleton" as "only one exists" and "it exists in the global scope". That is, if I create one instance of something in my `int main()` that's not enough for it to be a singleton. That's important, because there's more than one way to enter your program. Notably, tests don't flow through your main entrypoint.

Re: Are software engineering “best practices” just developer preferences?

#356

Post by mbrodersen » Sat, Oct 02, 2021, 2:25 AM UTC

SkipperCat wrote: post #266

cwp wrote: post #110

Eh, kinda. Calling something a "best practice" is basically an appeal to authority. It means, "this is the right way to do things, for reasons I don't have time to explain." There are times when that's appropriate. But really, "best" and "right" are highly situational. Any rule of thumb, even the most basic and uncontroversial, has a situation where it doesn't apply. I was part of a discussion on a mailing list years…

Sometimes "best practice" is not because we need to worship a standard, but we need to have a standard. If everyone does everything in a different manner, you wind up with a tower of babel and support becomes impossible. I'm of the mindset where an organization needs to agree to specific principles that everyone adheres. Not dogmatically but pragmatically. Having that shared "best practice" makes is easier to support…

My experience is that enforcing standards for everybody is really bad. Different projects are truly different and require different trade offs. Enforcing one way to do things is anti-agile.

Re: Are software engineering “best practices” just developer preferences?

#357

Post by mbrodersen » Sat, Oct 02, 2021, 2:27 AM UTC

asdff wrote: post #187

cwp wrote: post #110

Eh, kinda. Calling something a "best practice" is basically an appeal to authority. It means, "this is the right way to do things, for reasons I don't have time to explain." There are times when that's appropriate. But really, "best" and "right" are highly situational. Any rule of thumb, even the most basic and uncontroversial, has a situation where it doesn't apply. I was part of a discussion on a mailing list years…

Identifying a best practice is actually not as hard as people realize imo (although it may take some time), and only becomes hard when you let emotion and sources of emotion come into what should be a rational decision making process (such as preference for a certain tooling for reasons like familiarity or popularity in the field today rather than outright advantages vs other tooling). To identify the best practice f…

Two different “experts” will do this and arrive at different conclusions. Now what.

Re: Are software engineering “best practices” just developer preferences?

#358

Post by mbrodersen » Sat, Oct 02, 2021, 2:30 AM UTC

dragonwriter wrote: post #148

cwp wrote: post #110

Eh, kinda. Calling something a "best practice" is basically an appeal to authority. It means, "this is the right way to do things, for reasons I don't have time to explain." There are times when that's appropriate. But really, "best" and "right" are highly situational. Any rule of thumb, even the most basic and uncontroversial, has a situation where it doesn't apply. I was part of a discussion on a mailing list years…

> Calling something a "best practice" is basically an appeal to authority. If presented on its own, but then, any conclusion presented on its own without supporting context and analysis is the same. > But really, "best" and "right" are highly situational A description of a best practice that doesn't provide a sufficiently precise description of the situation to which it applies as a best practice is generally inappro…

Smart experienced software developers disagree on “best practices” all the time. What is “obviously” the best practice to you is “obviously” not the best practice for somebody else. Now what?

Re: Are software engineering “best practices” just developer preferences?

#359

Post by mbrodersen » Sat, Oct 02, 2021, 2:41 AM UTC

elboru wrote: post #46

Right, but have you ever worked in a place where no practices at all are being followed? Where there are hacks after hacks, giant classes with giant methods, no interfaces, static methods, bad names everywhere, you need to find a bug? good look, you want to write a test to avoid regression? Ok that would take you 5 times more time. I agree, following a “best practice” without understanding the “bad practice” that it’…

Most places I have worked had zero agreed standards. It wasn’t a problem at all. And people didn’t waste their time getting into fights about how to interpret the “agreed standards” or policing it. Great!

Re: Are software engineering “best practices” just developer preferences?

#360

Post by mbrodersen » Sat, Oct 02, 2021, 2:44 AM UTC

KronisLV wrote: post #53

> You can’t do it “correctly” if “correct” is “whatever the guy who’s been here longer wants.” To be honest, "correctly" is whatever actually works. But since we as an industry haven't been around for a long time and don't collectively know what actually works, it is simply the case that we defer to those who have comparatively more experience, so that we may get decent solutions now, as opposed to excellent ones lat…

I think you will find that there is a large set of ways to solve the same problem equally well. So arguing about the best way to solve the problem is a waste of time.