Thought leaders spent the last couple of decades propaganding that features-per-week is the only metric to optimize, and that if your software has any bit of efficiency or quality in it that’s a clear indicator for a lost opportunity to sacrifice it on the alter of code churning.
The result is not “amazing”. I’d be more amazed had it turned out differently.
No, never! Tech corps (both devs and app stores) brainwashed people into thinking “no updates = bad”.
Recently, I have seen people complain about lack of updates for: OS for a handheld emulation device (not the emulator, the OS, which does not have any glaring issues), and Gemini protocol browser (gemini protocol is simple and has not changed since 2019 or so).
Maybe these people don’t use the calculator app because arithmetic was not updated in a few thousand years.
A big part of this issue is mobile OS APIs. You can’t just finish an android app and be done. It gets bit rot so fast. You get maybe 1-2 years with no updates before “this app was built for an older version of android” then “this app is not compatible with your device”.
It’s kind of funny how eagerly we programmers criticize “premature optimization”, when often optimization is not premature at all but truly necessary. A related problem is that programmers often have top-of-the-line gear, so code that works acceptably well on their equipment is hideously slow when running on normal people’s machines. When I was managing my team, I would encourage people to develop on out-of-date devices (or at least test their code out on them once in a while).
Premature optimisation often makes things slower rather than faster. E.g. if something’s written to have the theoretical optimal Big O complexity class, that might only break even around a million elements, and be significantly slower for a hundred elements where everything fits in L1 and the simplest implemention possible is fine. If you don’t know the kind of situations the implementation will be used in yet, you can’t know whether the optimisation is really an optimisation. If it’s only used a few times on a few elements, then it doesn’t matter either way, but if it’s used loads but only ever on a small dataset, it can make things much worse.
Also, it’s common that the things that end up being slow in software are things the developer didn’t expect to be slow (otherwise they’d have been careful to avoid them). Premature optimisation will only ever affect the things a developer expects to be slow.
Optomisation often has a cost, weather it’s code complexity, maintenance or even just salary. So it has to be worth it, and there are many areas where it isn’t enough unfortunately.
How is that mindset lazy? Unhappy customers also have a cost!
At my last job the customer just always bought hardware specifically for the software as a matter of process, partly because the price of the hardware compared to the price of the software was negligible. You literally couldn’t make a customer care.
In industrial software, I’m sure performance is a pretty stark line between “good enough” and “costing us money”.
The pattern I’ve seen in customer facing software is a software backend will depend on some external service (e.g. postgres), then blame any slowness (and even stability issues…) on that other service. Each time I’ve been able to dig into a case like this, the developer has been lazy, not understanding how the external service works, or how to use it efficiently. For example, a coworker told me our postgres system was overloaded, because his select queries were taking too long, and he had already created indexes. When I examined his query, it wasn’t able to use any of the indexes he created, and it was querying without appropriate statistics, so it always did a full table scan. All but 2 of the indexes he made were unused, so I deleted those, then added a suitable extended statistics object, and an index his query could use. That made the query run thousands of times faster, sped up writes, and saved disk space.
Most of the optimization I see is in algorithms, and most of the slowness I see is fundamentally misunderstanding what a program does and/or how a computer works.
Slowness makes customers unhappy too, but with no solid line between “I have what I want” and “this product is inadequate”.
Are you really asking how it’s lazy to pass unoptimized code to a customer and make their hardware do all the work for you because optimization was too costly?? Like I get that you are in an Enterprise space, but this mentality is very prevalent and is why computers from today don’t feel that much faster software wise than they did 10 years ago. The faster hardware gets, the lazier devs can be because why optimize when they’ve got all those cycles and RAM available?
And this isn’t a different at you, that’s software development in general, and I don’t see it getting any better.
It’s not just software development, it’s everywhere.
Devices are cheap, people are expensive. So it’s not lazy, he’s being asked to put his expensive time into efforts the customer actually wants to pay for.
If having him optimize the code further costs way more than buying a better computer, it doesn’t make sense economically for him to waste his time on that.
Is that yet another example of how the economy has strange incentives? For sure, but that doesn’t make him lazy.
I never called them lazy, I stated that the mentality is lazy, which it is. Whether or not that laziness is profit driven, it still comes down to not wanting to put forth the effort to make a product that runs better.
Systemic laziness as profit generation is still laziness. We’re just excusing it with cost and shit, and if everyone is lazy, then no one is.
If cost is a justification for this kind of laziness, it also justifies slop code development. After all, it’s cheaper that way, right?
Wouldn’t he only be lazy if he’s not doing anything else more productive instead?
He gets payed to do a specific job, and does it the best way possible given the constraints. I don’t see how you find lazyness in that.
The customer simply isn’t willing to pay the extra time for it to be optimized, and he ain’t doing it for free.
I don’t know which job you do, but do you spend a lot of voluntary overtime just to do things the customer isn’t even asking or paying for just because you think it’s better?
Thought leaders spent the last couple of decades propaganding that features-per-week is the only metric to optimize, and that if your software has any bit of efficiency or quality in it that’s a clear indicator for a lost opportunity to sacrifice it on the alter of code churning.
The result is not “amazing”. I’d be more amazed had it turned out differently.
Fucking “features”. Can’t software just be finished? I bought App. App does exactly what I need it to do. Leave. It. Alone.
No, never! Tech corps (both devs and app stores) brainwashed people into thinking “no updates = bad”.
Recently, I have seen people complain about lack of updates for: OS for a handheld emulation device (not the emulator, the OS, which does not have any glaring issues), and Gemini protocol browser (gemini protocol is simple and has not changed since 2019 or so).
Maybe these people don’t use the calculator app because arithmetic was not updated in a few thousand years.
A big part of this issue is mobile OS APIs. You can’t just finish an android app and be done. It gets bit rot so fast. You get maybe 1-2 years with no updates before “this app was built for an older version of android” then “this app is not compatible with your device”.
“More AI features”? Of course we can implement more AI features for you.
It’s kind of funny how eagerly we programmers criticize “premature optimization”, when often optimization is not premature at all but truly necessary. A related problem is that programmers often have top-of-the-line gear, so code that works acceptably well on their equipment is hideously slow when running on normal people’s machines. When I was managing my team, I would encourage people to develop on out-of-date devices (or at least test their code out on them once in a while).
Premature optimisation often makes things slower rather than faster. E.g. if something’s written to have the theoretical optimal Big O complexity class, that might only break even around a million elements, and be significantly slower for a hundred elements where everything fits in L1 and the simplest implemention possible is fine. If you don’t know the kind of situations the implementation will be used in yet, you can’t know whether the optimisation is really an optimisation. If it’s only used a few times on a few elements, then it doesn’t matter either way, but if it’s used loads but only ever on a small dataset, it can make things much worse.
Also, it’s common that the things that end up being slow in software are things the developer didn’t expect to be slow (otherwise they’d have been careful to avoid them). Premature optimisation will only ever affect the things a developer expects to be slow.
Optomisation often has a cost, weather it’s code complexity, maintenance or even just salary. So it has to be worth it, and there are many areas where it isn’t enough unfortunately.
And that lazy mentality just passes the cost to the consumer.
How is that mindset lazy? Unhappy customers also have a cost! At my last job the customer just always bought hardware specifically for the software as a matter of process, partly because the price of the hardware compared to the price of the software was negligible. You literally couldn’t make a customer care.
In industrial software, I’m sure performance is a pretty stark line between “good enough” and “costing us money”.
The pattern I’ve seen in customer facing software is a software backend will depend on some external service (e.g. postgres), then blame any slowness (and even stability issues…) on that other service. Each time I’ve been able to dig into a case like this, the developer has been lazy, not understanding how the external service works, or how to use it efficiently. For example, a coworker told me our postgres system was overloaded, because his select queries were taking too long, and he had already created indexes. When I examined his query, it wasn’t able to use any of the indexes he created, and it was querying without appropriate statistics, so it always did a full table scan. All but 2 of the indexes he made were unused, so I deleted those, then added a suitable extended statistics object, and an index his query could use. That made the query run thousands of times faster, sped up writes, and saved disk space.
Most of the optimization I see is in algorithms, and most of the slowness I see is fundamentally misunderstanding what a program does and/or how a computer works.
Slowness makes customers unhappy too, but with no solid line between “I have what I want” and “this product is inadequate”.
Are you really asking how it’s lazy to pass unoptimized code to a customer and make their hardware do all the work for you because optimization was too costly?? Like I get that you are in an Enterprise space, but this mentality is very prevalent and is why computers from today don’t feel that much faster software wise than they did 10 years ago. The faster hardware gets, the lazier devs can be because why optimize when they’ve got all those cycles and RAM available?
And this isn’t a different at you, that’s software development in general, and I don’t see it getting any better.
It’s not just software development, it’s everywhere. Devices are cheap, people are expensive. So it’s not lazy, he’s being asked to put his expensive time into efforts the customer actually wants to pay for. If having him optimize the code further costs way more than buying a better computer, it doesn’t make sense economically for him to waste his time on that.
Is that yet another example of how the economy has strange incentives? For sure, but that doesn’t make him lazy.
I never called them lazy, I stated that the mentality is lazy, which it is. Whether or not that laziness is profit driven, it still comes down to not wanting to put forth the effort to make a product that runs better.
Systemic laziness as profit generation is still laziness. We’re just excusing it with cost and shit, and if everyone is lazy, then no one is.
If cost is a justification for this kind of laziness, it also justifies slop code development. After all, it’s cheaper that way, right?
Wouldn’t he only be lazy if he’s not doing anything else more productive instead?
He gets payed to do a specific job, and does it the best way possible given the constraints. I don’t see how you find lazyness in that.
The customer simply isn’t willing to pay the extra time for it to be optimized, and he ain’t doing it for free.
I don’t know which job you do, but do you spend a lot of voluntary overtime just to do things the customer isn’t even asking or paying for just because you think it’s better?
Exactly the mindset responsible for the state of modern software.
Your spelling is terrible
Bro just denied bro’s lemmy comment pull request
Oops, forgot the AI step