Hacker News Reader

Comment by mewpmewp2 | Hacker News Reader

People seem to always talk in absolutes, black and whites, concerning this topic.

In my experience most engineers take a situational approach. Sometimes it is worth it to optimize early, sometimes it is not. Some things are worth optimizing, some not. Also some things are worth optimizing to certain level.

These types of articles and claims conjure up a debate because everyone is imagining a different scenario in their heads. It is entirely plausible that each claim could be the best solution in a different scenario.

Do these articles assume that engineers are incapable of thinking flexibly and need to follow some absolute truths that have to be debated? Have I been around too good engineers that I have not noticed this issue?

View on HN

I think maybe yes, you've been around mostly good engineers.

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.

Absolutes can be indispensable when learning. An entire concept can be boiled down to black-and-white, and often can be completely forgotten about while a learner groks the rest of a subject. Part of the path to expertise for a learner is to go back and challenge those absolutes, because those absolutes are now part of the learner's assumptions.

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

> Do these articles assume that engineers are incapable of thinking flexibly and need to follow some absolute truths that have to be debated?

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.

Speculation time (not a linguist): I think this is an inherent problem in human languages, they're fundamentally not sophisticated enough to communicate nuances. We see this all the time in engineering, politics etc. People always talk in terms of rules because these are easier to phrase, but in reality everyone takes every decision situation-by-situation basis. But then when you need to explain these nuances, you simply need to use more words.

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.

IMO part of this is that nuanced processing is actually a very expensive operation and people would be unable to function without some level of abstraction- language as in all things. That's why, for example, Jeff Vandermeer writes in his Wonderbook that each author has a "thorn", something that bugs them and compels them to write and explore infinite nuances of the topic of their focus.

I think it's systemic, not really linguistic. Complexities are fractal, and there's fundamentally no way to succinctly express them in a title or summary.

I just finished a project where literally everything had been over engineered to the point that it took them weeks to do a release.

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.

> dictionaries of possible classes

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

Sounds like a group of people succumbing to the inner platform effect: https://en.wikipedia.org/wiki/Inner-platform_effect

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

It doesn't sound like inner-platform-effect to me. teddyuk didn't say they were reinventing the wheel, just that they were doing awful things with dictionaries.

I started reading the article:

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

They might as well hand a development tool to a client and call it a day ;) Super flexible

>Do these articles assume that engineers are incapable of thinking flexible

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 read somewhere else yesterday that “it’s easier to throw hardware at a problem than people.” It certainly does not hold true for all cases, but turning this aphorism into a question seems to give us some good heuristics---provided you do know the what the root cause of your performance issues could be, of course.

A rather large sector of software where you don't throw hardware at the problem is embedded software. Shipping hardware that is 25€ more expensive times a million is often much more expensive than optimizing the software.

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.

The i.MX6 is certainly a poor choice today but do you know of any good contemporary alternatives? Honest curiosity because personally I can't think of any medium-power (or at least thermal dissipation), (Mainline-) Linux capable, well (and openly) documented processor available long-term in low/medium quantities from a proven vendor.

I've recommended Toradex Tegra 2 modules to a customer (I got involved early enough to recommend hardware - a rare case) and they seem to be quite happy with it. Just a few euros more per module than i.MX6 from the same module vendor. The GPU is unsurprisingly (with nVidia making the whole SoC) pretty good. Most everything needed for software support except the user-space graphics driver is even open source. I am not an nVidia fan because of their desktop Linux driver shenanigans, but I strongly prefer Tegra 2 over i.MX6. By the way, i.MX6/6+/7 with the etnaviv driver might also be alright. I've just never used anything but the proprietary "gal3d" driver.

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.

It's easy to throw hardware at a problem that can be parallelized efficiently. It's very hard to throw hardware at inherently sequential solution.

It was easy to throw hardware at a sequential problem, a decade ago. CPUs were still improving their single-core performance year after year, and memory access and all kinds of IO devices kept getting faster and better. I'm guessing that time was where this idea originates from.

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.

It is also a bit less easy to throw hardware at a problem when your software is actually embedded firmware. Upgrading or adding hardware reduces your profit per unit.

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.

In cases where you control the hardware and the problem is sufficiently parallelizable.

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

This is partly what I was trying to convey with the "turning this aphorism into a question" fragment. Sometimes it is just not possible, or it is too expensive, to increase hardware performance.

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

People seem to always talk in absolutes, black and whites, concerning this topic.

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.

Reply on news.ycombinator.com