Are software engineering “best practices” just developer preferences?

Which is why I don't buy the "software has only been around for 70 years so give it time" argument. Software has nothing to be grounded in like other engineers do with physics. It's most likely always going to be endless cargo culting.

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

It took the ancient civilizations hundreds if not thousands of years to perfect architecture to a reasonable degree, where it's possible to be fairly certain about the viability of most typical designs, as well as the tradeoffs that nonstandard ones might require.

Personally, i think that we'll only be able to talk about what truly works and what doesn't once the industry cools down - when there are new JS frameworks once a month or once a year as opposed to every day (or for any technology, really). When there are very few breaking framework changes, because the frameworks would finally be stable. When the primitives around doing web development, interfacing with devices and everything else have been distilled to their most usable possible forms. When a developer doesn't need 10 languages or 20 frameworks to do their job, but can instead rely upon a few, after most others would have died off after a sort of singularity of languages.

That's when useful certifications would be possible. That's when estimates wouldn't be guesswork. That's when the education systems could actually prepare people fully for working in the industry. That's when the development of projects wouldn't be such Wild West, but instead would be a process with far higher quality, a true engineering discipline even at the expense of projects taking longer to actually develop, much like you don't construct buildings in an ad hoc fashion.

Now, whether that will happen in a 100 years, a 1000 years or never, is another question entirely.

There's all kinds of non mission-critical software that gets made with little life/death consequence on how it gets made. There doesn't seem to be the same notion of the "bridge that barely stands" in software either since compute power can be thrown at something way cheaper than a rewrite. Thus, when it comes to the people that make software, there's a wild amount of interpretation on what "good" means and here we are.

And if I can opine on your Spring Boot example, unit testing can sometimes be easier for mock purposes if you have a set of interfaces (vs concrete classes) to work with.

Interfaces serve two roles:

1. They are (usually) concise specification/contract for the implementation to follow, and for the client to use.

2. They permit substitution.

These are, from my experience, the principle and most useful reasons to make use of "redundant" interface definitions. What's worse is when people want alternative implementations but only have a concrete instance, they subclass it and break all kinds of contracts making their square peg fit a round hole.

This is less useful when you have ducktyping and consequently every lookalike is considered substitutable for each other.

We're definitely still figuring out what the best practices are. In my relatively short career as a software developer, we've already flipped back and forth between separation of concerns is important when it comes to views, styling, and logic. (Frontend dev)

Gone are the days when we threw together a php, html, and JavaScript in one file... wait, or is it?