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

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

#251

Post by asdff » Thu, Sep 30, 2021, 11:32 PM UTC

lucumo wrote: post #230

asdff wrote: post #187

Earlier quoted context omitted.

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…

That sounds like a beautiful example of letting perfect be the enemy of good. Just like your design choices have trade-offs, is it important to realize that there's a trade-off between finishing sooner and making a better solution. Diminishing returns are usually very much in play with analysis. (I would also challenge the notion that every situation has a different "best practice". That's just creating a solution. "…

You shouldn't take forever, but what I'm saying is a best practice emerges after doing however much due diligence. Maybe you spend an hour looking into it and that's it, but you should do your due diligence to vet what sort of approaches you can take to solve your particular problem as best you can, so you can make the best decision based on the evidence you've been able to find within however much time you are working with. A professor gave me a word of advice once, "a week in a library can save a month in the lab."

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

#252

Post by ori_b » Thu, Sep 30, 2021, 11:42 PM UTC

sagichmal wrote: post #248

ww520 wrote: post #245

Earlier quoted context omitted.

For service directory lookup, global variable is fine. For global scope queue, global variable is fine. For global scope logging service, global variable is fine.

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.

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

#253

Post by milesvp » Thu, Sep 30, 2021, 11:44 PM UTC

dmalik wrote: post #60

> How can Software Engineers call themselves engineers when there’s no rules, governing bodies, or anything to stipulate what true Software Engineering is? We call ourselves software developers in Canada. According to Canadian engineering[1]: The "practice of engineering" means any act of planning, designing, composing, evaluating, advising, reporting, directing or supervising, or managing any of the foregoing, that…

So what do you call electrical engineers who design consumer level non mains voltage hardware? Looks like they fail the second bullet point. Sort of an honest question, since most of what you’d likely learn in an EE degree would probably not fall under number 2 either.

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

#254

Post by qball » Thu, Sep 30, 2021, 11:45 PM UTC

wruza wrote: post #247

psyc wrote: post #205

Earlier quoted context omitted.

I aggressively refuse to call myself an engineer. Programmer is fine. Developer is better, because programming is only a piece of it. Y’all can call yourselves whatever you like, but inside I’m thinking you retconned an industry insider euphemism into a non-existent sub-type of engineering, by protesting all the ways you apply rigor to what we do.

Isn’t it easier to just stick to the term and not fight with it? Everyone involved knows that “software engineering” is not like “civil engineering”, and those who don’t, usually don’t know either. It has no legal nor practical sense, so why bother?

>It has no legal nor practical sense, so why bother?

You might be surprised to know that it actually does matter, and it matters in a way that depresses American software engineer salaries: work visas.

The fact that the US government considers "software engineering" to be equal to "civil engineering" means that the TN visa (since we're talking about Canada) applies to people qualified to be employed as software engineers in the US.

As such, this visa allows tens of thousands of equally-qualified software engineers from Canada to compete for a good proportion of the same jobs thereby depressing American wages; why wouldn't an American software engineer (or a Canadian P.Eng who wants to make a business but can't afford the better engineers) be opposed to the weak American definition being the only one that really matters?

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

#255

Post by psyc » Thu, Sep 30, 2021, 11:50 PM UTC

wruza wrote: post #247

psyc wrote: post #205

Earlier quoted context omitted.

I aggressively refuse to call myself an engineer. Programmer is fine. Developer is better, because programming is only a piece of it. Y’all can call yourselves whatever you like, but inside I’m thinking you retconned an industry insider euphemism into a non-existent sub-type of engineering, by protesting all the ways you apply rigor to what we do.

Isn’t it easier to just stick to the term and not fight with it? Everyone involved knows that “software engineering” is not like “civil engineering”, and those who don’t, usually don’t know either. It has no legal nor practical sense, so why bother?

It didn’t used to bother me back when I could assume everyone else understood it was an industry specific title based on a metaphor! I even used to defend the title by saying, “Relax; it’s an industry-specific title, not a kind of engineer.” Like “Software Architect” is understood not to be a kind of architect. But over the last few years I’ve seen dozens of HNers lay out technical arguments for why they ARE engineers.

So, I never took a single engineering class, have no engineering cert, don’t know much about the ethos, and barely even know the definition without looking it up. But I’m supposed to not rock the boat, and claim to be one, like I accidentally became an engineer in the course of designing, planning, fortifying, testing, and measuring software? Like Daniel-san accidentally became a karate master by waxing cars?

Sorry, no. Our “engineering” is just another partially applicable metaphor for what software devs do. But software development is its own set of disciplines. It’s wonderful to pull helpful concepts from other disciplines, but I draw the line at coopting the whole designation.

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

#256

Post by urda » Thu, Sep 30, 2021, 11:59 PM UTC

isbvhodnvemrwvn wrote: post #234

urda wrote: post #216

Earlier quoted context omitted.

> What of those who graduated from engineering programs taught at engineer colleges? We are the actual Engineers. For US-Based IT workers, that means a degree from an ABET [1] backed institution with a traditional undergrad and graduate programs. Anyone else calling themselves an "engineer" while doing IT work are not. In addition: Readers need to remember this isn't reddit and downvoting comments with facts you do n…

I would trust someone graduating with CS degree from non-ABET accredited Stanford rather than someone from ABET-accredited CS program of Athens State University.

... Except Stanford is ABET accredited, and as are all the major Engineering institutions and leaders.

The fact that most users here are reaching to downvote literally the fact that leading Engineering institutions all fall in this bucket is absolutely depressing from this community. It's clear some feelings have been "hurt" here by other users having higher educations.

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

#257

Post by userbinator » Fri, Oct 01, 2021, 12:00 AM UTC

Jorengarenar wrote: post #195

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…

> somebody got flamed harshly when he mentioned using a global variable. Harsh bashing on global variables is such a dumb thing. Yes, they can be dangerous. Yes, many had problems due to using them. Yes, we should tell beginners to avoid globals. But there is no reason to ban them altogether. Experienced programmers should utilize them whenever it makes sense (instead of passing down a value of a local one to almost…

On the contrary, I think beginners should use them because it reduces cognitive load in tiny applications.

My standard rebuttal to anti-global dogmatism is "there's only one instance, and never needs to be more. If/when we do, we can consider doing something else."

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

#258

Post by lucumo » Fri, Oct 01, 2021, 12:01 AM UTC

afarrell wrote: post #54

fitzn wrote: post #4

Steven Sinofsky gave a talk and said something to the effect of, we've been building roads, bridges and edifices for thousands of years. So, best practices and solved problems abound---and even then we still get it wrong sometimes. Whereas, software engineering is maybe 70 years old (generously)? So, there is much to learn and a lot of "baseline" knowledge that has yet to be established. I think it's a good way to th…

Also, there isn't that much in the way of scientific grounding. Mechanical engineering has physics as a foundation. Chemical engineering has chemistry as a foundation. What is the scientific foundation of software engineering? I suspect it is a mix of cognitive science, linguistics, and anthropology.

> I suspect it is a mix of cognitive science, linguistics, and anthropology.

I agree. Creating a solution that is clear to navigate for future developers is valuable, as is one that is flexible for future modifications. These things depend much more on how humans understand the code than on how machines understand it.

That said, other engineering disciplines aren't entirely bereft of that kind of human aspect either. Take architecture for example. It's critical for a building to handle the forces put on it. But it's also important that humans can use it. Having a good building layout is much more a matter of understanding humans than of understanding physics.

And then there's the whole style thing that architecture has. A building is not always only functional. It can very much be a work of art. And that style is not just decorative. A style can conjure up certain emotions to put people in a certain mindset when dealing with the building. (E.g. putting a modern art museum in a neo-classical building would be dissonant.)

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

#259

Post by throwaway889900 » Fri, Oct 01, 2021, 12:06 AM UTC

gpderetta wrote: post #232

throwaway889900 wrote: post #213

Earlier quoted context omitted.

Singletons come to mind as being a better alternative in languages that can do that sort of thing.

Singleton is just a fancy name for a global.

Ah, but they come with the benefit that you are forced to only ever make one. A global doesn't prevent you from doing that, so singletons are ever so slightly better.

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

#260

Post by kelnos » Fri, Oct 01, 2021, 12:07 AM UTC

theptip wrote: post #125

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…

One thought to add here - when you appeal to an authority, which one is it? In the OP example, it seems the senior dev is saying “on my authority”. And sometimes that is enough, especially if the senior dev can give examples of when not following this practice bit them. But sometimes there is a higher authority, such as “it’s what is recommended in Google’s SRE book”, which is probably good advice if you are building…

> All that said, sometimes as the senior engineer you need to go with gut feel; “this design smells like it will give us trouble within a year” is the sort of thing I sometimes say.

That's a really great perspective. There are a bunch of times where I have a preference for or against something, but I can't point to a specific example of when that thing was good/bad, or any objective data about it. It's just that my experience suggests to me (via murky pattern matching in my brain) that particular thing will be good or bad.

It's certainly weaker evidence than data or concrete examples, but I think it's still valuable and worthy of consideration.