Live data from Hacker News

Are software engineering “best practices” just developer preferences?

floverfelt.org

331–340 of 369 posts

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

#331
post #68

Earlier quoted context omitted.

What about we apply this to software engineering? > If a builder constructs a house for a man but does not make it conform to specifications so that a wall then buckles, that builder shall make that wall sound using his own silver. - Code of Hammurabi, 1755–1750 BC

The software is as sturdy as the day it was written, there has been no deterioration - if your copy has become broken, the builder can easily supply another copy using his own silver. On the other hand, if the customer finds out that their door is inconvenient and it would be much better to have it a bit to the right, noone expects a house builder to fix that at their expense, you bought what you saw. And the same th…

Unfortunately only consulting and high integrity computing are the main areas where software companies get liability for delivering faulty products.

One day that will extend to everyone like in all industries.

Who can't manage then closes doors, just like bad restaurants after a surprise health check.

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

#332

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…

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

I’ve seen the other way around too - senior developers rejecting or pushing changes that they find convenient. IME it’s not to do with experience, rather stubbornness.

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

#333

> Java is infamous for its verbosity. [...] This paragraph highlights something I've been saying for ages. Most criticism of Java needs to be directed towards Java programmers and not the language itself. The language allows you to simply make a class. You're not required to make an interface and then make a class that implements it, and yet, Java programmers do it anyways and then criticize the language for being ve…

Thank you. I have programmed Java for years, but it's been frustrating. The clean language I learnt at university, that I love to bits, seems to be used approximately nowhere.

Instead, it's always some monstrosity held together by inheritance, XML/(awful) Gradle and liberal sprinklings of magical annotations that always (always!) bite you in the backside at runtime rather than at compile time, because why would you prefer to have good tooling that takes advantage of static typing to tell you what might go wrong.

I am appalled by what Spring mentality did to my language.

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

#334

Earlier quoted context omitted.

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…

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

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

#335

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…

> I hate the expression "best practice", it's so, so often used by someone to justify applying cargo cult without actually understanding why.

> Most of the time it could be replaced by "tradition", "pattern", or "the way I've seen others do".

The most common valid / defensible case I've seen it used is when a person fully understands the "why" in depth, and have formed that understanding on the basis of experience (not blind following or "tradition"), but doesn't have time to deliver a long in-depth explanation every time they do a code-review.

That's not to say it isn't still "developer preferences": there are multiple "best-practice" approaches out there and some even contradict eachother. But I strongly believe that even many of the very subjective, hotly-debated approaches are valid and useful in certain contexts.

e.g. I personally lean toward a pseudo-FP style of programming and am growing less and less enamoured with OO patterns for various reasons. But OO is still a useful abstraction, and if you're doing OO, I've found something like SOLID to contain a great deal of wisdom. I never sat down and decided to do things "the SOLID way", and learned that. Rather I wrote a lot of bad OO, ran into problems, gained insight from experience, and later stumbled across SOLID and found the pitfalls it mitigates familiar.

A sibling commenter has the following quote, which I agree with:

> SOLID is especially funny because majority of developers doesn't understand / can explain it, let alone have read papers

I think this is exactly why the term "best-practice" is so popular. I would not have understood SOLID in any depth if I had come to it fresh: I needed to learn SOLID informally by accident, internalise the challenges it's designed to overcome, and then recognise that intuitively from my experience when reading about SOLID later.

That's not a level of understanding you can typically impart easily in a conversation when suggesting someone do something differently. It's much easier to just say "best-practice".

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

#336
post #330

Earlier quoted context omitted.

> The language allows you to simply make a class. You're not required to make an interface and then make a class that implements it, and yet, Java programmers do it anyways and then criticize the language for being verbose. That's the 'D' in SOLID -- dependency inversion. An object's dependencies should be defined in terms of abstract interfaces, not concrete classes. The verbosity is just boilerplate, and it would a…

> That's the 'D' in SOLID -- dependency inversion. An object's dependencies should be defined in terms of abstract interfaces, not concrete classes DI does not talk about the interface keyword in Java. It talks about interface as the public surface of an object or system. Programming to a Java interface declaration does not guarantee the code is depending on higher-level abstractions - this depends on how the interfa…

I.e. (together with the S and I) this implies that the interface should be defined by its immediate consumer and should consist of all and only the methods required to implement the functionality in the most straightforward way (i.e. the consumer shouldn't have to deal with the idiosyncrasies of the provider).

On most languages this requires a lot of boilerplate and indirections though.

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

#337

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…

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…

That big backing relational database of yours contains tables of "global mutable variables". The non local side effects are part of the point.

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

#338
post #24

Software engineering seems partially creative partially technical - so on the creative parts, yes absolutely teams should self define their preferences. Scrum vs agile vs whatever else IMO should be a team/org preference. However like someone else said some engineering has to be liable for criminal prosecution in some cases. So you need some practices to be enforced.

Sure, so who defines which parts are highly technical? We can all be in agreement that things like cryptography should use well known and vetted libraries, whereas something like a REST API interface can be a little more relaxed with adherence to a standard, but where do we draw the line? I do not want to live in a world where my code must conform to a Java Bean factory class. I align more with the skunkworks style o…

It’s a difficult question and I’m not qualified to answer it as an amateur tbh.

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

#339

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.

I don't think that it's changed that much over the decades of my career, really. The words used change, but the concepts seem reasonably stable.

New batches of commonly accepted practices come into play with new technologies, though, and most of the "hot" technologies today are still so new that the "accepted practices" unique to them have still not settled down. So, yes, in that space, they change rapidly because they don't yet really exist.

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

#340
post #224

Earlier quoted context omitted.

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…

Exactly what I was trying to get across. The protected term is meaningless even if enforced, it seems to me, because there are no "reserved tasks," as you say.

It's bit like... being able to practice law as long as you don't call yourself a lawyer. You're a legal assistant instead. In a similar fashion developers are practising software engineering without calling themselves, "engineers."

I don't think we all need to be licensed in order to work -- but companies should be required to hire X number of licensed engineers per Y number of developers. They should be required to pay for the liability insurance to hire those licensed engineers. And there should be repercussions if the company goes against the engineers' direction.

Post reply on HN