Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Are software engineering “best practices” just developer preferences?

floverfelt.org

Post reply on HN
Print view View original

311–320 of 369 posts

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

#311

Post by irjustin »

Yes...?? And what's wrong with that?

"Best Practices" means - given this problem set, these other engineers have tried a number of ideas and put together a framework, idea, code, whatever that represents a *good enough* solution.

There is no such thing as literal best, greatest, perfect. We're all just balancing tradeoffs in the "best" way we can.

For teams, consistency is more important than cleverness. If something needs to be "clever" then it is important enough to become consistently used because if the person who built the "clever" thing leaves, it becomes expensive to maintain it.

That's what "best practices" are, they are a consistent set methods that enough people have tried them that allows you to "stand on the shoulder of giants" and focus on more critical problems.

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

#312

Post by lmm »

Chris2048 wrote: post #210
Jorengarenar wrote: post #195

Earlier quoted context omitted.

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

But here's the thing: aren't most alternatives to global, some other kind of global state anyway, but possibly better managed?

You can just... not. Give the thing an explicit scope and lifecycle. Maybe that's actually "program lifespan", but if you make that "execution of the main() function" rather than just "IDK, somewhere", you have more visibility and control.

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

#313

Post by sowbug »

The best best practices I've heard usually have stories behind them. Someone did or didn't do X, and bad thing Y happened. Therefore we do or don't do X in the hopes of avoiding Y again.

The danger is that X keeps happening without the story of Y also being passed along; otherwise it turns into the Five Monkeys problem (https://intersol.ca/news/organizational-culture-and-the-5-mo...).

I'm not disagreeing with the author's friend's point. But at least if there's a story attached to the practice, then it's less of an appeal to authority and more of collective wisdom that can continue to evolve.

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

#314

Post by lmm »

WorldMaker wrote: post #201
mywittyname wrote: post #186

Earlier quoted context omitted.

> So why is there so much resistance? Because, 1) a PE license is useless for software/computer engineering. 2) the FE exam covers a bunch of irrelevant material. 3) once you pass the FE exam, there's no real mechanism to advance because there are no apprenticeships available in computer engineering. And you can't take the PE exam without the apprenticeship. My college spent a lot of money getting an ABET accreditati…

Most companies already have the "apprenticeship" half-codified in "Junior Developer" versus "Senior Developer" distinctions or "Level Ranks" or other ladders like that. If you switch jobs mid-"apprenticeship" today in the software industry depending on who you interview with and how well you can negotiate you either "start over" at a low rank/level/job title or luck/bs into "skipping that step" and jumping to a highe…

> Most companies already have the "apprenticeship" half-codified in "Junior Developer" versus "Senior Developer" distinctions or "Level Ranks" or other ladders like that. If you switch jobs mid-"apprenticeship" today in the software industry depending on who you interview with and how well you can negotiate you either "start over" at a low rank/level/job title or luck/bs into "skipping that step" and jumping to a higher rank/level/job. Standardizing that across the industry wouldn't necessarily be a bad thing for the industry.

In my experience no-one cares who's "junior" or "senior" day-to-day, and no-one can compare levels across multiple companies, and that's good for the industry; I've worked with plenty of "juniors" who were better than corresponding "seniors", standardising and formalising some years-of-experience metric would make the industry much less meritocratic.

> Similarly, PE licenses would be so hugely worth it to the industry if it saved everyone time in "technical interviews", both interviewees and interviewers alike. How many collective labor hours as an industry are we wasting annually on "technical interviews"? For most classic Civil Engineering firms the "technical" part of the interview is almost entirely "Is your PE license valid and up to date?" "Yes." "Great, you're hired." The software industry would rather waste multiple hours (if not entire days) of wages of everyone involved instead, and it's rather sad when you think about it.

I've yet to find any software-related qualification that wasn't an active negative. I've worked in a place that applied the acknowledged "best practices" of 10 years ago and it was a terrible environment for producing good code.

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

#315

Post by w0mbat »

dcow wrote: post #288
throwaway889900 wrote: post #261

Earlier quoted context omitted.

If you expect that sort of thing to occur, then your get method should be synchronized to prevent it.

These days in both Java and Swift you can just lazily reference a static class field/property set to an instance of the singleton (in java the field must be on a dedicated private class) and the Runtime will lazily initialize it exactly once in a thread-safe manner the first time it is referenced.

That's only the tip of the iceberg I'm afraid. If the singleton has methods that perform actual work asynchronously and different threads are hammering on it, all kinds of issues come up. Of course a seasoned developer is going to acticipate this and write the needed infrastructure, but a newbie is not. It can be better if different threads have their own worker objects with their own state for example.

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

#316

Post by midnightclubbed »

sowbug wrote: post #313

The best best practices I've heard usually have stories behind them. Someone did or didn't do X, and bad thing Y happened. Therefore we do or don't do X in the hopes of avoiding Y again. The danger is that X keeps happening without the story of Y also being passed along; otherwise it turns into the Five Monkeys problem ( https://intersol.ca/news/organizational-culture-and-the-5-mo... ). I'm not disagreeing with the a…

Sometimes those historically best practices become outdated but clung onto as doctrine by programmers who let experience get in the way of evolution.

What may have been true 10 years ago may no longer be accurate or important but is still held up as a best practice today.

If allowed to evolve then we are all good but finding the correct speed of evolution (and helping everyone evolve at a similar speed) is harder than ideal. Flip-side of that is the organization or programmer that blindly chases the new.

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

#319

Post by avgcorrection »

Jtsummers wrote: post #191
avgcorrection wrote: post #189

Earlier quoted context omitted.

> Getters and Setters also permit you to specify that something can only be retrieved or assigned, but not the other. Only retrieved? `final` and set the fields through the constructor. Sure someone could implement setters-only if they wanted that. Except I’ve never seen it and get/set are always used instead. Just one layer of indirection for no benefit.

That's not equivalent. You may want a field to be updated by other actions. That is, its value is derived from the other properties of the system. You could recompute those on each request, but that's potentially costly. You could also recreate the entire object with each small field change. That's also very costly. Consider a collection class which has a size field. `final` would be the wrong thing to use. If you ex…

A collection is a red herring. A collection uses a “getter” for the size since the size is not something you get/set like in a value object.

But then again no one calls it a “getter” (not even Java calls it `getSize()`) since the get/set discussion is about updatable fields, not the inner guts of objects.

Has anyone argued against encapsulation? No one has.

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

#320

Post by andi999 »

cptaj wrote: post #282
poulsbohemian wrote: post #264

The biggest issue I saw with "best practices" in my career is the failure to take into account who it claiming it to be a best practice, and in what context . I saw too many junior developers read a rando blog article, then get a non-technical / semi-technical manager excited about something that made their life easier, even though it was by no means a good practice for the context at hand. Or alternatively, believe…

Managers excited about a new tech idea are probably the most destructive thing in the industry.

Nah, just rewrite the code base.
Post reply on HN