It's not a problem that's exclusive to coding, you find people talking loudly about absolutes in most fields. People like definitive answers. Makes us feel secure.

Which makes absolutes easy to sell, and especially popular with people who feel out of their depth. It also makes them popular in academics.

You also find flexible, creative thinkers in the same fields. They're just not as loud, or as numerous, in my experience.

When people espouse absolutes, I generally (not absolutely) assume either they're not experts or they think their audience can't handle nuance.

I think this article assumes that there are possibly engineers that don't think flexibly and need to follow some "absolute truths".

> Have I been around too good engineers that I have not noticed this issue?

Probably. I mean, I would love to be between your colleagues.

In some places, submission to ideas rumored to be proven is valued more than flexible thinking, critical thinking at any time, etc. I know that some countries in Asian have a rather high degree of culture like this. It doesn't apply to everyone.

I think this also makes sense. Take a cat. Cats clearly are able to think a lot more complex than they can communicate. They use a set of very basic body cues to communicate, but they are able to process information a lot more complex than these. Why would this not be like this humans too?

I have some very opinionated friends on coding styles, libraries, programming languages, programming "rules", "principles" etc... They're all sort of rubbish. I think it's important to know and study them because they give you different ways to think of engineering. But when it's time to commit code to production does anyone really think about "ah this is not DRY, premature optimization, NIH etc...". I claim no. We always think about the specific situation. Is it good to invent this code. Is it good to optimize this possible future extension. Is it good to repeat this particular code. We all know repeating code is "bad" but we all also know reasonable exceptions.

So yes, all rules are by nature fuzzy. In fact, whenever someone tells me a principle they hold, I immediately start thinking about fuzzy-fying it i.e. thinking of possible niche cases where this principle would reasonably NOT hold.

The code generally had one path but every method was built using dictionaries of possible classes that would implement interfaces so they wouldn’t have any duplicate code.

Sometimes some dev teams go down the wrong path.

Sounds like a horror show built by people who don't understand OOP.

It's not nearly as uncommon as I'd like.

“ The inner-platform effect is the tendency of software architects to create a system so customizable...”

Yup, that was it and I have seen it so many times - architects should think that a flexible system that “can just” handle any possible future requirement. This always ends in a mess of junk that isn’t actually needed by the business.

There are some developers that are like that, they read in a book about some patterns or idea and then in code reviews will jump on you because you did X wrong and not followed his bellowed pattern from the book.

I've also seen the opposite, quite often actually: Cheaping out on hardware that is going to ship maybe 1-10k (very expensive) units, then spending hundreds of thousands on optimizing software to make it not even good, just less painfully slow. The i.MX6 chip with its weak GPU and corresponding wonky drivers is an especially popular way to get user interfaces that can't keep 60 fps.

Regarding mainline Linux support, AFAIK you don't get mainline Linux support anyway with i.MX6 and the gal3d driver. You can only use mainline with etnaviv, which is semi-officially(?) supported by Pengutronix. I've heard others say good things about etnaviv.

Today, things are different. Single-threaded performance isn't going to be improving much in foreseeable future; the effort shifted to improving parallel performance and, more recently, power consumption. So if you write slow code - perhaps by choosing a slow software stack - your code will remain slow.

But TBH in this particular field Moore's law still rules. Sometimes you are forced to upgrade to a better component for the same price because the component you chose five years ago has reached end-of-life.

Yet paying attention about optimization allows you to do more with what you have, or sometimes allows you to use less optimal but more convenient or simpler approaches.

If you are releasing consumer applications either your program works smoothly on the device a consumer has or not, let alone has the ability to buy either financially or fundamentally (as in you don’t find a phone with desktop level performance anywhere, because they don’t simply exist).

Premature optimization, or at least one of its manifestations, is failing to consider the opposite.

Maybe this is just my cynical perception, but I often hear people try to justify situational bad practice by citing outliers unrelated to the situation at hand, particularly with optimization. As you say, they usually imagine a different scenario is at hand. For those situations I quote HL Mencken:

Explanations exist; they have existed for all time; there is always a well-known solution to every human problem—neat, plausible, and wrong.

I interpret the premature optimization dictum to mean:

Really the only time to talk about optimization at the early stage of a project is to set performance objectives or when the project is about optimization. Otherwise people should seek relatively optimal solutions which optimize efficiency at delivery. Optimization starts when they have running code that doesn't meet performance goals. Other optimization is premature, in one sense or another.