10 ms·

There is an easy explanation for this: developers optimize their code when the product owner tells them to spend time on this. The product owner will tell them

There is an easy explanation for this: developers optimize their code when the product owner tells them to spend time on this. The product owner will tell them to optimize when product owner notices that the software is getting too slow. When new hardware is released, slowdowns that would be visible on older hardware won't be easily noticeable, so programmers will work on other features rather than optimizing code. Until the code becomes too slow to run on current hardware, then they work until it becomes usable again.

tsjq 6y ago
Totally this
AmericanChopper 6y ago
The thing hardware engineers are missing here is that people don’t want to use their improvements to improve speed. They want to use them to pay for more expensive abstractions that allow them to develop software faster. Unless you have a performance issue that’s really pathological, speed really doesn’t matter for most applications. I’ve developed dozens of python web applications. Python is slow as hell, but I can count on one hand the number of times hand where I found the RoI of optimizing a performance issue to be more valuable than feature development (and all of them were problems that couldn’t be solved with more hardware, which is the default best-RoI way to approach most performance issues).
- nitrogen 6y ago
  I think distinguishing between client-side and server-side speed matters. Python and Ruby are fast enough, and as you say you can scale them horizontally for a long time before it gets cheaper to optimize or rewrite in another language. But if a UI is slow, that does matter. Delayed keypresses, unacknowledged but registered interactions, or the worst, delayed layout changes, are completely flow breaking.
  - AmericanChopper 6y ago
    I think my rationale applies to client side code too, just in a slightly different way. It is so easy to write performant browser UIs these days, and a lot of that is down to these same sorts of hardware improvements (as well as V8 improvements). Even bloated web app front ends will perform very well most of the time. You can take that to the extreme of course, but you really have to go out of your way to do it. I’ve built frontends before without giving any consideration at all to performance, and they’ve always performed perfectly well. Websites like cnn.com exist, so it is demonstrably possibly to do it badly, but you have to stray so far from the light accomplish something like that.
  - josephg 6y ago
    Yes. And the resulting churn and dissatisfaction is mostly invisible, unless you go looking for it. Most users don't even file bug reports when things are actually broken. Most users can't tell why they don't like something when it just runs slowly. Even technical users will almost never file bug reports against slow and janky performance. I hate Jira - but I think the main reason is just that it feels slow to use. A slow UI gives a visceral felt sense of lethargy / sickness, which I associate with the product. Is that a bug? I don't know. But I bet it runs fast enough internally at atlassian. And I suspect the PMs at atlassian tell themselves the same story - that its not worth the development time to make it fast. And that might match with the feedback they get, because all the users who care about that have probably already bounced to other products.
    - AmericanChopper 6y ago
      Jira is bad for a completely different reason. Jira is bad because Atlassian has grown from a company that sold software to its users, to a company that sells software to people who work in corporate procurement. Atlassian only has to impress two people to make a sale now. The person box ticking the features, and the person who wants to see the reports that it produces, and neither of those people are the ones who actually use the software.
      - VBprogrammer 6y ago
- birksherty 6y ago
  > people don’t want to use their improvements to improve speed I don't agree. It's only software developers that think that way with their latest gadgets, fast internet at high tech buildings; not the users.
  - AmericanChopper 6y ago
    Users tend not to think about these sort of trade offs at all. Users will also complain about not having the features they want just as readily as they will complain about something being slow. But that’s really besides the point. As long as an application is fast enough that a user doesn’t notice a problem with it, then you’re done optimizing for performance (in most cases at least). So if new hardware comes out that’s twice as fast, you could very sensibly keep the performance at the same acceptable level, and use the new performance budget in other ways. Such as by introducing various inefficiencies via abstractions that make feature development faster.
    - saagarjha 6y ago
      The issue is that not all users can buy that new hardware that’s twice as fast.
      - AmericanChopper 6y ago
        This is just a further misunderstanding of the market. People optimize for who their customers are. Knowing what devices your code runs on is trivially easy, and so is measuring its performance against them. People aren’t going to instantaneously make their code 20x slower just because the new Apple chip is so good. But they’re also not going to optimize for that old Samsung phone that represent 0.0003% of their user base.
- tjansen 6y ago
  Yes. I would assume that the only metrics that count for CPU engineers are performance, power consumption and cost. Features are not a relevant metric. What was the last CPU feature that was not added to improve performance? Virtualization support?
  - tylerhou 6y ago
    Security mitigations for side channel attacks?
- ratww 6y ago
  You're really projecting if you think normal people give a crap about expensive abstractions or even speed of development. Most of those "abstractions" and "development" are working against the user anyway: most webpages have not added features in more than 20 years but still require more power because developers can't get their shit together. Speed is the reason people bought SSDs. It's the whole core of Apple's M1 Marketing. It's probably the biggest reason why people buy new computers. Lack of speed is the reason I had to throw away my Smart TV after 8 years of useless upgrades. People pay more for faster internet because they want more movies in bigger quality or to download big things faster. Not because they give a crap about your shitty app. > Unless you have a performance issue that’s really pathological, speed really doesn’t matter for most applications And that's only true because developers are constantly forcing hardware developers and customers to throw money at the problem.
toshk 6y ago
A common believe among my non developer friends is that apple does it on purpose so their users need to keep buying new hardware. I don't know if they do, but at least their incentive is not very big to keep old devices running smooth.
- ojnabieoot 6y ago
  Apple and Samsung have both paid fines and settlements recently because of deliberately slowing down older devices - most recently Apple in November: https://finance.yahoo.com/news/apple-u-states-reach-113-180435514.html https://finance.yahoo.com/news/apple-u-states-reach-113-1804...
  - megablast 6y ago
    This was an attempt to save the battery. Where Apple messed up was not talking about this feature.
    - oblio 6y ago
      I'm a bit tired of this Apple apologism. Do you think that a corporation with their market cap is not fully aware of these kinds of decisions that impact their sales? This is the same company that removed the headphone jack for very cynical reasons, in order to increase the sale price of their phone by $150 (or however much the Airpods cost). The same company that repeatedly removed ports from the laptops in order to sell more dongles (so much so that there were running gags at the time about Apple, the dongle company). A company where the revenue from the sale of accessories for their devices could literally make a Fortune 1000 company (!!!). They definitely knew what they were doing and chose to do the thing that most benefited their bottom line. Let's stop giving the benefit of the doubt to the top tech companies. They don't deserve it like mom and pop stores. Oblio's Law: Never attribute to malice that which can be attributed to stupidity, unless the ones acting have an army of data scientists, researchers, market analysts and PR people at their disposal.
      - jlokier 6y ago
polote 6y ago
in my previous job, as a PM, I was creating tickets all the time to work on the speed of the app, but the developers didn't not want to work on them, they were saying the users don't care. The reality is that they didn't know how to fix the speed issues. It is easy to debug a js function, but what about when you use angular or any other js framework ?
- megablast 6y ago
  Or they are unfixable. And explaining why to a non technical pm can take all day.
  - polote 6y ago
    that was not the case, I ended being the one plotting the flame charts as no-one wanted to do it
    - Aeolos 6y ago
      Similar experience as a PM and as a technical director: the vast majority of devs, outside maybe 3d rendering or HPC, do not understand nor care about performance optimization. Implementing some feature, fixing a bug, refactoring code to improve DX? Sure, happy to do, you don’t even have to ask. Plotting tail response times, flame charts, allocation pressure, DOM changesets, database execution plans? No chance, unless the PM forces the matter. My hope is that some of that can be taught and embedded into the team culture, but the reality is that day-to-day web development is simply too far abstracted from the underlying software and hardware, and getting your average javascript programmer to care about milliseconds is an uphill battle. The sad thing is that users do definitely care, and the evidence shows up again and again: user behaviour tests for 100ms vs 500ms responses, the reviews of the new M1 processors, ...
      - TeMPOraL 6y ago
        > Plotting tail response times, flame charts, allocation pressure, DOM changesets, database execution plans? Is anybody even teaching people these things? I do the above as a matter of course, but I've learned how and why through osmosis, over the years, mostly because I dabble with gamedev as a hobby (and because I care about performance). None of that was covered in any of my university courses. And, out of the people I worked with, I was and am literally the only one who knows how to do any of that.
bjornsing 6y ago
Yup. And the result of this algorithm is of course that the software is always barely usable.
helloycombinat 6y ago
Sometimes I wonder if it's because people don't really pay for software. Photoshop doesn't really have competition. xcode is free. Why bother improve either of things? Hell besides C++ compilers seem to be slow af. D is unfunded and mostly been written by 1 guy (Walter). It's faster than Go which people say is fast and go was written by a team (source https://i.imgur.com/FIcgRwd.png https://i.imgur.com/FIcgRwd.png, from page https://imgur.com/a/jQUav https://imgur.com/a/jQUav). I'm pretty sure compilers can do > 100K lines per core per second easily but I haven't confirmed if any does. I'd bet 100K on anyone who takes it that compilers can do 200K per core per second or 500+ using multiple cores. No cheating with a simple brainfuck language or having everything you need defined ahead of time like C++ does with headers
MaxBarraclough 6y ago
When the topic of bloat comes up, I often point out that it's only a problem in certain software domains. High-performance game engines must (by definition) be performance-competitive or they'll be out of business. They don't bloat in the way messaging applications have over the decades.
atlantis_ 6y ago
the onus should be upon not surrounding yourself with the latest technology - supporting old hardware and upcycling computers. here in my city I can pull out a sticky mud-encrusted motherboard and GPU from the flea markets - scrub it down with a bit of isopropyl alcohol, and put together something as responsive as a 2015 macbook air for 20 euro (PopOS is a favourite for this). in an agency, you have an MBP thrust upon you, and your software “works fine on [our] computers”. end users still be running a last generation of CPU will eventually decide “I need a new computer”, and the cycle is complete. its not that developers dont care, its that they’re never given the chance to care under these ... circumstances.
- tomaskafka 6y ago
  There are cases of dev teams intentionally limiting themselves - Microsoft Windows Mobile OS developers having last gen devices (200 Mhz in times when flagships were 3x faster), Google web devs developing on a proxy which simulates developing country internet (low speed, high packet loss and jitter).
arendtio 6y ago
There is another aspect: Game engine developers tend to use high-end hardware during development, because they anticipate that next years hardware will be stronger. While there is certainly some truth to it, mostly the effect is not as strong as the developers hope it is.
divbzero 6y ago
I subscribe to the theory that Moore’s Law was in part a self-fulfilling prophecy, in that the expectation that transistor density should double every two years led to product roadmaps that aimed to hit that target. If only we could popularize an analogous law for software performance…
xallaboutx 6y ago
For optimization look into computer networking, that's where all the competing-for-lower-latency-programmers hang out, developing routers and switches.

tsjq 6y ago

Totally this

AmericanChopper 6y ago

The thing hardware engineers are missing here is that people don’t want to use their improvements to improve speed. They want to use them to pay for more expensive abstractions that allow them to develop software faster. Unless you have a performance issue that’s really pathological, speed really doesn’t matter for most applications. I’ve developed dozens of python web applications. Python is slow as hell, but I can count on one hand the number of times hand where I found the RoI of optimizing a performance issue to be more valuable than feature development (and all of them were problems that couldn’t be solved with more hardware, which is the default best-RoI way to approach most performance issues).

nitrogen 6y ago
I think distinguishing between client-side and server-side speed matters. Python and Ruby are fast enough, and as you say you can scale them horizontally for a long time before it gets cheaper to optimize or rewrite in another language. But if a UI is slow, that does matter. Delayed keypresses, unacknowledged but registered interactions, or the worst, delayed layout changes, are completely flow breaking.
- AmericanChopper 6y ago
  I think my rationale applies to client side code too, just in a slightly different way. It is so easy to write performant browser UIs these days, and a lot of that is down to these same sorts of hardware improvements (as well as V8 improvements). Even bloated web app front ends will perform very well most of the time. You can take that to the extreme of course, but you really have to go out of your way to do it. I’ve built frontends before without giving any consideration at all to performance, and they’ve always performed perfectly well. Websites like cnn.com exist, so it is demonstrably possibly to do it badly, but you have to stray so far from the light accomplish something like that.
- josephg 6y ago
  Yes. And the resulting churn and dissatisfaction is mostly invisible, unless you go looking for it. Most users don't even file bug reports when things are actually broken. Most users can't tell why they don't like something when it just runs slowly. Even technical users will almost never file bug reports against slow and janky performance. I hate Jira - but I think the main reason is just that it feels slow to use. A slow UI gives a visceral felt sense of lethargy / sickness, which I associate with the product. Is that a bug? I don't know. But I bet it runs fast enough internally at atlassian. And I suspect the PMs at atlassian tell themselves the same story - that its not worth the development time to make it fast. And that might match with the feedback they get, because all the users who care about that have probably already bounced to other products.
  - AmericanChopper 6y ago
    Jira is bad for a completely different reason. Jira is bad because Atlassian has grown from a company that sold software to its users, to a company that sells software to people who work in corporate procurement. Atlassian only has to impress two people to make a sale now. The person box ticking the features, and the person who wants to see the reports that it produces, and neither of those people are the ones who actually use the software.
    - VBprogrammer 6y ago
birksherty 6y ago
> people don’t want to use their improvements to improve speed I don't agree. It's only software developers that think that way with their latest gadgets, fast internet at high tech buildings; not the users.
- AmericanChopper 6y ago
  Users tend not to think about these sort of trade offs at all. Users will also complain about not having the features they want just as readily as they will complain about something being slow. But that’s really besides the point. As long as an application is fast enough that a user doesn’t notice a problem with it, then you’re done optimizing for performance (in most cases at least). So if new hardware comes out that’s twice as fast, you could very sensibly keep the performance at the same acceptable level, and use the new performance budget in other ways. Such as by introducing various inefficiencies via abstractions that make feature development faster.
  - saagarjha 6y ago
    The issue is that not all users can buy that new hardware that’s twice as fast.
    - AmericanChopper 6y ago
      This is just a further misunderstanding of the market. People optimize for who their customers are. Knowing what devices your code runs on is trivially easy, and so is measuring its performance against them. People aren’t going to instantaneously make their code 20x slower just because the new Apple chip is so good. But they’re also not going to optimize for that old Samsung phone that represent 0.0003% of their user base.
tjansen 6y ago
Yes. I would assume that the only metrics that count for CPU engineers are performance, power consumption and cost. Features are not a relevant metric. What was the last CPU feature that was not added to improve performance? Virtualization support?
- tylerhou 6y ago
  Security mitigations for side channel attacks?
ratww 6y ago
You're really projecting if you think normal people give a crap about expensive abstractions or even speed of development. Most of those "abstractions" and "development" are working against the user anyway: most webpages have not added features in more than 20 years but still require more power because developers can't get their shit together. Speed is the reason people bought SSDs. It's the whole core of Apple's M1 Marketing. It's probably the biggest reason why people buy new computers. Lack of speed is the reason I had to throw away my Smart TV after 8 years of useless upgrades. People pay more for faster internet because they want more movies in bigger quality or to download big things faster. Not because they give a crap about your shitty app. > Unless you have a performance issue that’s really pathological, speed really doesn’t matter for most applications And that's only true because developers are constantly forcing hardware developers and customers to throw money at the problem.

toshk 6y ago

A common believe among my non developer friends is that apple does it on purpose so their users need to keep buying new hardware. I don't know if they do, but at least their incentive is not very big to keep old devices running smooth.

ojnabieoot 6y ago
Apple and Samsung have both paid fines and settlements recently because of deliberately slowing down older devices - most recently Apple in November: https://finance.yahoo.com/news/apple-u-states-reach-113-180435514.html https://finance.yahoo.com/news/apple-u-states-reach-113-1804...
- megablast 6y ago
  This was an attempt to save the battery. Where Apple messed up was not talking about this feature.
  - oblio 6y ago
    I'm a bit tired of this Apple apologism. Do you think that a corporation with their market cap is not fully aware of these kinds of decisions that impact their sales? This is the same company that removed the headphone jack for very cynical reasons, in order to increase the sale price of their phone by $150 (or however much the Airpods cost). The same company that repeatedly removed ports from the laptops in order to sell more dongles (so much so that there were running gags at the time about Apple, the dongle company). A company where the revenue from the sale of accessories for their devices could literally make a Fortune 1000 company (!!!). They definitely knew what they were doing and chose to do the thing that most benefited their bottom line. Let's stop giving the benefit of the doubt to the top tech companies. They don't deserve it like mom and pop stores. Oblio's Law: Never attribute to malice that which can be attributed to stupidity, unless the ones acting have an army of data scientists, researchers, market analysts and PR people at their disposal.
    - jlokier 6y ago

polote 6y ago

in my previous job, as a PM, I was creating tickets all the time to work on the speed of the app, but the developers didn't not want to work on them, they were saying the users don't care. The reality is that they didn't know how to fix the speed issues. It is easy to debug a js function, but what about when you use angular or any other js framework ?

megablast 6y ago
Or they are unfixable. And explaining why to a non technical pm can take all day.
- polote 6y ago
  that was not the case, I ended being the one plotting the flame charts as no-one wanted to do it
  - Aeolos 6y ago
    Similar experience as a PM and as a technical director: the vast majority of devs, outside maybe 3d rendering or HPC, do not understand nor care about performance optimization. Implementing some feature, fixing a bug, refactoring code to improve DX? Sure, happy to do, you don’t even have to ask. Plotting tail response times, flame charts, allocation pressure, DOM changesets, database execution plans? No chance, unless the PM forces the matter. My hope is that some of that can be taught and embedded into the team culture, but the reality is that day-to-day web development is simply too far abstracted from the underlying software and hardware, and getting your average javascript programmer to care about milliseconds is an uphill battle. The sad thing is that users do definitely care, and the evidence shows up again and again: user behaviour tests for 100ms vs 500ms responses, the reviews of the new M1 processors, ...
    - TeMPOraL 6y ago
      > Plotting tail response times, flame charts, allocation pressure, DOM changesets, database execution plans? Is anybody even teaching people these things? I do the above as a matter of course, but I've learned how and why through osmosis, over the years, mostly because I dabble with gamedev as a hobby (and because I care about performance). None of that was covered in any of my university courses. And, out of the people I worked with, I was and am literally the only one who knows how to do any of that.

bjornsing 6y ago

Yup. And the result of this algorithm is of course that the software is always barely usable.

helloycombinat 6y ago

Sometimes I wonder if it's because people don't really pay for software. Photoshop doesn't really have competition. xcode is free. Why bother improve either of things? Hell besides C++ compilers seem to be slow af. D is unfunded and mostly been written by 1 guy (Walter). It's faster than Go which people say is fast and go was written by a team (source https://i.imgur.com/FIcgRwd.png https://i.imgur.com/FIcgRwd.png, from page https://imgur.com/a/jQUav https://imgur.com/a/jQUav). I'm pretty sure compilers can do > 100K lines per core per second easily but I haven't confirmed if any does. I'd bet 100K on anyone who takes it that compilers can do 200K per core per second or 500+ using multiple cores. No cheating with a simple brainfuck language or having everything you need defined ahead of time like C++ does with headers

MaxBarraclough 6y ago

When the topic of bloat comes up, I often point out that it's only a problem in certain software domains. High-performance game engines must (by definition) be performance-competitive or they'll be out of business. They don't bloat in the way messaging applications have over the decades.

atlantis_ 6y ago

the onus should be upon not surrounding yourself with the latest technology - supporting old hardware and upcycling computers. here in my city I can pull out a sticky mud-encrusted motherboard and GPU from the flea markets - scrub it down with a bit of isopropyl alcohol, and put together something as responsive as a 2015 macbook air for 20 euro (PopOS is a favourite for this). in an agency, you have an MBP thrust upon you, and your software “works fine on [our] computers”. end users still be running a last generation of CPU will eventually decide “I need a new computer”, and the cycle is complete. its not that developers dont care, its that they’re never given the chance to care under these ... circumstances.

tomaskafka 6y ago
There are cases of dev teams intentionally limiting themselves - Microsoft Windows Mobile OS developers having last gen devices (200 Mhz in times when flagships were 3x faster), Google web devs developing on a proxy which simulates developing country internet (low speed, high packet loss and jitter).

arendtio 6y ago

There is another aspect: Game engine developers tend to use high-end hardware during development, because they anticipate that next years hardware will be stronger. While there is certainly some truth to it, mostly the effect is not as strong as the developers hope it is.

divbzero 6y ago

I subscribe to the theory that Moore’s Law was in part a self-fulfilling prophecy, in that the expectation that transistor density should double every two years led to product roadmaps that aimed to hit that target. If only we could popularize an analogous law for software performance…

xallaboutx 6y ago

For optimization look into computer networking, that's where all the competing-for-lower-latency-programmers hang out, developing routers and switches.