[TeMPOraL]

I think so too. It's not about ASM snippets; it's about people not knowing what their software actually does. Software bloat isn't magic, nor is it static; your CPU is doing something. If with time application gets bigger and slower, and yet no extra features appear to explain it, it means your CPU is running code that shouldn't be run, wasting its cycles on pointless and irrelevant computations. That's laziness and/or stupidity.

[prof_hobart]

It's not laziness or stupidity (well, it might be sometimes, but certainly not always).

It's using your time to do something else, such as improving security, or adding a new feature. Some people seem to be talking as if it automatically takes the same amount of time to create efficient code as inefficient code, and the idiot developer has simply forgotten to add the -run_faster option on the compiler.

I'm involved in a project at the moment where a team of developers and engineers have spent much of the last month trying to get response times in some very specific circumstances in an application down to an acceptable level. That's not because they are either stupid or lazy. It's because these things are hard - there's an awful lot of moving parts, and an awful lot of things that can go wrong in each of them.

When they get it down to an acceptable level, they'll ship it to the users. It won't be blazingly fast, but it'll be good enough. They could definitely spend longer tuning it further and getting it going even faster. But every day they do that will be a day longer until the features that the users want are actually available to them.

[JoeAltmaier]

Perhaps too many moving parts. Engineers are criticized for 'reinventing the wheel' and writing code when open source is available. But use too much open source, and you have too many moving parts, you don't know how they work, and things like locks and latency are uncontrollable. A familiar storey!

[prof_hobart]

Apart from the OS (which isn't where the problem lies), there's no open source in it.

The reason there's lots of moving parts is because modern computers, OSs, languages, application servers, libraries, databases etc are built to do a lot of very complicated things.

We could have written the entire application from scratch, not using any 3rd party elements so that we had full control over every element. But that would have taken several orders of magnitude longer to deliver actual useful working software to the users.

[JoeAltmaier]

Or, to be non-Aristotelian about it, some parts could have been dispensed with and appropriate code written for the purpose, and other more robust parts could be kept.

[prof_hobart]

Until you discover the issues, you don't know which bits aren't robust enough.

And rewriting them, along with modifying the rest of the application to use them, takes time and can lead to further unexpected behaviour.

[JoeAltmaier]

The opposite of that. Using somebody else's code, written for a different app in a different environment, is where most unexpected behavior comes from.

Here's the bits that aren't robust enough: any open source that isn't either used by thousands, or used in exactly the way you will be using it.

[wongarsu]

>That's laziness and/or stupidity

Or the failure of a large team to properly manage software complexity.

[prof_hobart]

Or higher priority things to work on. Optimisation doesn't come for free.