[Cthulhu_]

Which in itself is a short form of "make it work, make it pretty, make it fast, in that order", which tackles both over-engineering on an architectural and a performance level.

For the vast majority of any task that requires writing code, performance is the least of your concerns; your code is fast enough, your compiler and runtime is fast enough, the hardware is fast enough. Use decent algorithms / don't do anything stupid (e.g. n+1 if you use an ORM), but don't fret too much whether it's fast enough either.

If your code is working and pretty, nine times out of ten it's fast enough. For the last 10%, measure before you make assumptions.

[friendzis]

> For the vast majority of any task that requires writing code, performance is the least of your concerns;

I always have conflicting thoughts when faced with such statements. On one hand, you are right - in many cases any single code unit you write is not going to be the performance bottleneck anyway, and if it is you can optimize it later.

On the other hand, there are scaling characteristics, both algorithmic and architectural. Once you chose architecture that is just bad at the scale you target, it is going to be increasingly difficult to change that.

I guess the takeaway here is that we often forget the distinction between code performance and product performance.

[xyzzy123]

Also conflicted, but I find myself happier working with "the dumbest thing that barely works" for a first release of something. To me, this is "optimal engineering under uncertainty".

Obviously, there are limits. And maybe a difference in perspective here reflects our respective typical uncertainty.

I'd rather optimise based on user feedback and with production traces than "in a vacuum".

Very often I don't even know if the feature or product is a good idea or how much / whether anyone will actually use it.

Optimisations usually come at the cost of some flexibility and this can hurt when there's a need to evolve the product in a direction I didn't expect (and for some reason that happens way more often than it seems like it should).

[imtringued]

>To me, this is "optimal engineering under uncertainty".

Information acquisition costs are the worst, aren't they? They are everywhere and they don't appear neatly on your bill.

[sanitycheck]

> For the vast majority of any task that requires writing code, performance is the least of your concerns;

Maybe, but it's perhaps not as rare as you think.

My main current project exists because development of the previous version was aborted after a year due to fundamental technology/architecture choices which it turned out would never achieve sufficient performance on the target devices.

Yesterday I was handed someone elses Android app to debug, it turns out to take 8 minutes for each (incremental!) compile for some reason. That's a performance problem which hugely slows down development.

A couple of years ago I wrote a moderately complicated one-way sync script to take data from one system and feed it into another. I had to artificially limit number of requests per minute to about 200 because apparently otherwise I was putting "massive load" on the target system causing it to auto-scale up several times. This was mostly GETs which the occasional small POST/PUT. Something very wrong there!

[Pannoniae]

This approach of "things being fast enough" leads to everything being slightly slow - we literally had better usability and latency on our devices in the 90s than we have now. It all adds up.

[Shaanie]

Another way to think about it is that software that focus on performance loses market share to software that focuses on other things.

[Pannoniae]

And that's a perverse incentive, and we must evaluate why that is the case. It doesn't have to be that way.

[evandale]

It probably has to do with the fact that a lot of people are patient enough to wait 10 seconds for something to finish if a) they understand it and b) it does the job.

The average person will put up with a lot of friction to use something they're familiar with and needs a lot of incentive to change. If your thumbnails fail to load every 10000 times or every 100000th profile picture upload fails most people will just retry and hope it works the second time, not find a different service or app to use.