Live data from Hacker News

Are software engineering “best practices” just developer preferences?

floverfelt.org

221–230 of 369 posts

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

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

> Yes, we should tell beginners to avoid globals.

Welcome to Dependency Injection in .Net Core!

"Those who cannot remember the past are condemned to repeat it." -- George Santayana

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

#222

I hate the expression "best practice", it's so, so often used by someone to justify applying cargo cult without actually understanding why. "Hey why are you having a try-catch there, it seems like it's just gonna break our stack trace and we don't even graciously recover from it" - it's best practice "Hey why are you using model/view/controller folders?" - it's best practice "Why are you building microservices?" - be…

Same with Clean Code, SOLID, DD SOLID is especially funny because majority of developers doesn't understand / can explain it, let alone have read papers e.g [0], except maybe S letter, yet everybody acts like they do SOLID*. Or Clean Code's small function craziness or misinterpretation and going into "avoid comments" approach * - unless you ask for details [0] - https://www.cs.cmu.edu/~wing/publications/LiskovWing94.…

Interesting, I guess SOLID must have been a buzzword from an earlier era, because while I've vaguely heard of it I had to look it up. Don't think it's come up in my 8 years of professional work.

There's always an evolution of these methodologies and I often feel like in practice they're just a way to mix things up and make code health feel more interesting to those involved. Often people know there are problems with the design of their system, but they can't get buy in to fix them. These methodologies provide some authoritative justification for refactoring work.

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

#223

I've always used "best practices" as a nicer way of saying "commonly accepted". It's not really developer preferences -- there are a number of best practices that I don't prefer as a developer.

it feels like though, whats "commonly accepted" changes quite rapidly though doesnt it?

i think we probably need a more rigorous definition or else people will keep using "best practice" to justify what is actually a preference, and i think thats where conflicts start to happen within teams/orgs.

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

#224
post #92

Earlier quoted context omitted.

Microsoft lost their appeal in Quebec https://www.oiq.qc.ca/en/media/pressReleases/Pages/default.a...

That's interesting, thanks for sharing! INAL; it seems, to me, difficult to enforce. You're not allowed to call yourself an engineer but you can still practice as one as long as you call yourself a developer. What's the difference? In practice... very little. Most developers I know do all the things professional engineers do. Unless the government wants to step in and say that you're not allowed to release software w…

It's a bit like saying that you are a doctor, nurse or a lawyer (attorney?). In Canada these are protected titles that can only be used if you are part of a professional order that has oversight over your activities and can audit your work at basically any time. There are some tasks that can only be performed if you are certified and pay the annual fees.

Where this falls apart is that "Software Engineering" is a real discipline recognized by the organization that handles engineering programs in Canada, however there are no "reserved tasks" so a lot of Software Developers have a Software Engineering degree but can't call themselves that because they (rightfully in my opinion but still) refuse to pay the annual membership fees (about 600$) since their professional order is actually not equipped to audit software engineering work.

Hopefully that helps a little.

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

#225

Earlier quoted context omitted.

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. Computer Science (more abstract) and Computing Science (less abstract) are branches of Science that have given a foundation to Software Engineering. The problem is that most of the programming and software development that happens nowadays (and what people pay for) doesn't use it. I compare it as Chemistry and Alchemy. We are still in the "a…

I'm a computer science and computer engineering major, and I've never once heard the term "computing science". Is there a context in which this term is regularly used?

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

#226

Earlier quoted context omitted.

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

Almost assuredly better managed. There are no reasons to manage state on the global level apart from laziness.

Funny you should mention that. I've used ocornut's ImGui library in the past, with a single, hierarchical object that managed the entire GUI state.

This approach caused whole classes of problems that affect regular GUIs to simply disappear, and it was the most performant, least buggy UI I've ever written by a country mile.

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

#228

Earlier quoted context omitted.

Global mutable variables are generally a bad idea because they have nonlocal side effects which are difficult to mitigate, like aliased mutable pointers but worse. Extra non-aliasing arguments and multiple return values are free of these issues, and a better tradeoff in almost all cases (unless you're sure you'll never run 2 instances of a system in the same address space, and you have specialized constraints possibl…

> When experienced programmers utilize global variables whenever it makes sense, it tends to bite future generations. Usually. There is one pattern I keep using in Rails to inject the current_user for the request into the model layer. At the beginning of a request, Thread.current[:current_user] gets set to the current_user. At the end of the request, it's cleared. For those unfamiliar, each Thread has its own Hash ob…

> It's a way to create global variables scoped to the current thread.

That's not a global variable; that's a thread-scoped variable.

(It's also not (really) mutable. It gets initialized at the start of the scope and gets removed at the end of scope.)

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

#229

Make the simplest thing you possibly can, write lots of software tests and keep in mind that your code is a piece of communication to the next developer, like a story. Everything else is just vanity or preferences.

Lots of small, simple things can add up to a really complex and not very much maintainable result if you are not careful

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

#230
post #187
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…

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. "Best practices" are usually general advise that is applicable in most situations.)

Post reply on HN