5 ms·

> If 99.9% of your users (i.e. the lay users, excluding the experts in the HN crowd) don't perceive your program/page to be slow, why would you optimize further

> If 99.9% of your users (i.e. the lay users, excluding the experts in the HN crowd) don't perceive your program/page to be slow, why would you optimize further? And how do you know if they perceive it to be slow? I suspect that if you did optimize it to be faster (e.g. lower latency interactions), they would notice the improvement, even if they weren't sure why it "felt" better. > If speed/performance is a feature that your customers want to pay for, they will let you know. I don't buy that. Customers often don't even know it's a possibility that their software could be faster. In my experience, often lay users don't think of individual programs as being fast or slow. They either assume the "internet" is being slow, or their computer is slow. However, I think they do notice when performance is better. They say it "works better" or "feels more reliable", but they don't necessarily know why.

jayd16 6y ago
After a threshold the business value drops off substantially. How often does a consumer pick between competitors and choose based on speed? I would assume that's vastly in the minority. You see some shakeups here and there. A large push to a new browser once a decade, etc. but features are king most of the time.
- wtetzner 6y ago
  > After a threshold the business value drops off substantially. Sure, but I don't see any reason better tools couldn't get us closer. Instead of starting out with languages and tools that will almost guarantee slow software, maybe we work on designing languages that provide productivity while at the same time encouraging leaner software. I don't disagree that overall the environment software is developed in doesn't encourage lean software. But I do think it's worthwhile to see if there are ways to improve the situation. Also, faster software can often provide opportunities for new features that weren't possible before. For example, something that used to be a batch or background process can now become a real-time feature. That is something that customers likely would find useful.
  - theptip 6y ago
    > Instead of starting out with languages and tools that will almost guarantee slow software, maybe we work on designing languages that provide productivity while at the same time encouraging leaner software. The key point I'm making is that you need to consider the whole system/environment; developers aren't choosing "slow languages" because they simply don't care about performance, they are choosing those languages because they are more productive in other dimensions, and the return on that productivity gain exceeds the return on optimizing for more speed. > Also, faster software can often provide opportunities for new features that weren't possible before. Absolutely -- we do see performance improvements happen, when they give users something that they actually value; for example the reason IntelliJ triumphed over Eclipse was by doing more sophisticated compiling/parsing in real-time, which was only made possible by significant performance optimizations.
theptip 6y ago
> And how do you know if they perceive it to be slow? Ask them, or listen to what they are saying without you asking. (I.e. UI/UX research 101.) For an IDE with a large userbase (for example JetBrains' product line), there are plenty of bug reports / user reviews which complain about performance, and so it's possible to get a picture of how many users perceive your app to be slow. Note, I chose my words carefully there -- if your users don't perceive the site to be slow, they may still respond positively to imperceptible performance improvements. To measure that you do A/B experiments. There's a lot of ink spilled on this subject; Google has done some really good research here. > Customers often don't even know it's a possibility that their software could be faster. Fair, I probably oversimplified there. More precisely, "If speed/performance is a feature that your customers will pay for, you should be able to measure that fact." You don't necessarily need to invest in the performance improvements to measure this; when Goole investigated this they simply added artificial delay and measured the effects on revenue. From this you can estimate the gradient of the $-revenue / ms-latency slope, and figure out how much it's worth investing in improving your app/site's latency.
- cxr 6y ago
  > so it's possible to get a picture of how many users perceive your app to be slow. No, it isn't. That's "Recognizing Survivorship Bias 201".
  - theptip 6y ago
    Google would disagree with you: https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/34439.pdf https://static.googleusercontent.com/media/research.google.c...
    - cxr 6y ago
      Please point to the section of the paper you linked to that says Google believes that survivorship bias doesn't exist.
      - 6y ago

jayd16 6y ago

After a threshold the business value drops off substantially. How often does a consumer pick between competitors and choose based on speed? I would assume that's vastly in the minority. You see some shakeups here and there. A large push to a new browser once a decade, etc. but features are king most of the time.

wtetzner 6y ago
> After a threshold the business value drops off substantially. Sure, but I don't see any reason better tools couldn't get us closer. Instead of starting out with languages and tools that will almost guarantee slow software, maybe we work on designing languages that provide productivity while at the same time encouraging leaner software. I don't disagree that overall the environment software is developed in doesn't encourage lean software. But I do think it's worthwhile to see if there are ways to improve the situation. Also, faster software can often provide opportunities for new features that weren't possible before. For example, something that used to be a batch or background process can now become a real-time feature. That is something that customers likely would find useful.
- theptip 6y ago
  > Instead of starting out with languages and tools that will almost guarantee slow software, maybe we work on designing languages that provide productivity while at the same time encouraging leaner software. The key point I'm making is that you need to consider the whole system/environment; developers aren't choosing "slow languages" because they simply don't care about performance, they are choosing those languages because they are more productive in other dimensions, and the return on that productivity gain exceeds the return on optimizing for more speed. > Also, faster software can often provide opportunities for new features that weren't possible before. Absolutely -- we do see performance improvements happen, when they give users something that they actually value; for example the reason IntelliJ triumphed over Eclipse was by doing more sophisticated compiling/parsing in real-time, which was only made possible by significant performance optimizations.

theptip 6y ago

> And how do you know if they perceive it to be slow? Ask them, or listen to what they are saying without you asking. (I.e. UI/UX research 101.) For an IDE with a large userbase (for example JetBrains' product line), there are plenty of bug reports / user reviews which complain about performance, and so it's possible to get a picture of how many users perceive your app to be slow. Note, I chose my words carefully there -- if your users don't perceive the site to be slow, they may still respond positively to imperceptible performance improvements. To measure that you do A/B experiments. There's a lot of ink spilled on this subject; Google has done some really good research here. > Customers often don't even know it's a possibility that their software could be faster. Fair, I probably oversimplified there. More precisely, "If speed/performance is a feature that your customers will pay for, you should be able to measure that fact." You don't necessarily need to invest in the performance improvements to measure this; when Goole investigated this they simply added artificial delay and measured the effects on revenue. From this you can estimate the gradient of the $-revenue / ms-latency slope, and figure out how much it's worth investing in improving your app/site's latency.

cxr 6y ago
> so it's possible to get a picture of how many users perceive your app to be slow. No, it isn't. That's "Recognizing Survivorship Bias 201".
- theptip 6y ago
  Google would disagree with you: https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/34439.pdf https://static.googleusercontent.com/media/research.google.c...
  - cxr 6y ago
    Please point to the section of the paper you linked to that says Google believes that survivorship bias doesn't exist.
    - 6y ago