5 ms·

If slowness is the goal and if product managers insist on slowness, then you'd expect a lot of sleep() calls in commercial software (which has product managers)

by gizmo 10y ago

If slowness is the goal and if product managers insist on slowness, then you'd expect a lot of sleep() calls in commercial software (which has product managers) and no sleep() calls in open source software. This doesn't happen. What we see is that commercial software has better documentation, gets more long term maintenance and support, and supports more cumbersome enterprise features. Exactly what you'd expect when you have salespeople and product managers who talk to customers. Your hypothesis is falsifiable, which is a necessary but not a sufficient condition for it to be scientific. For it to be scientific you would also have to provide evidence that your hypothesis is more plausible than the alternatives, before you do any experiments. After all, it's easy to come up with thousands of silly hypothesis, and by happenstance some of them will get a positive correlation when tested. So every hypothesis has to undergo serious scrutiny.

logicallee 10y ago
>If slowness is the goal and if product managers insist on slowness, then you'd expect a lot of sleep() calls in commercial software (which has product managers) and no sleep() calls in open source software. This doesn't happen. Why do you say this doesn't happen, when it does, in fact, happen? An example of which would be this: http://osxdaily.com/2015/01/06/make-the-window-resizing-animation-speed-instant-in-mac-os-x/ http://osxdaily.com/2015/01/06/make-the-window-resizing-anim... This is a very explicit "sleep". It is far from the only one. Are you saying someone didn't think the slower animation was "better" than the faster animation - that the default time wasn't picked by a product manager? >What we see is that commercial software has better documentation, gets more long term maintenance and support, and supports more cumbersome enterprise features. Exactly what you'd expect when you have salespeople and product managers who talk to customers. We also see fancy loading graphics and I consider it extremely plausible that product managers consider fast/instant operation as room to add something to slow it down. I am not sure why you're debating this. Regarding your open-source claim, this comment - https://news.ycombinator.com/item?id=13940014#13940458 https://news.ycombinator.com/item?id=13940014#13940458 - shows that fancy progress bar animations are considered more important, even in a commandline utility, and even under Linux. In other words, the fact that these progress bar animations slowed core functionality by 50% was -- in point of fact -- not an issue. Someone spent the time to create them, test them, commit them, and these were accepted: someone considered it objectively (or subjectively) better. >Your hypothesis is falsifiable, which is a necessary but not a sufficient condition for it to be scientific. For it to be scientific you would also have to provide evidence that your hypothesis is more plausible than the alternatives, before you do any experiments. You don't think surveying the actual decisions made in cases (such as the two examples just quoted, the window animation speed and the progress bar speed) where there was no functional difference except slowness, to be a plausible reason for supposing that people in charge of these choices choose a slower version? I think it's quite plausible that for whatever reason, slow software is preferred explicitly and implicitly. >After all, it's easy to come up with thousands of silly hypothesis, and by happenstance some of them will get a positive correlation when tested. So every hypothesis has to undergo serious scrutiny. I didn't spend much time looking through it in the original leak (on Wikileaks) but Bruce Schneier quoted on his blog Do's and Don'ts by an intelligence agency: https://www.schneier.com/blog/archives/2017/03/the_cias_develo.html https://www.schneier.com/blog/archives/2017/03/the_cias_deve... The parts I'd like to draw attention to: - DO NOT perform operations that will cause the target computer to be unresponsive to the user (e.g. CPU spikes, screen flashes, screen "freezing", etc). - DO make all reasonable efforts to minimize binary file size for all binaries that will be uploaded to a remote target (without the use of packers or compression). Ideal binary file sizes should be under 150KB for a fully featured tool. Rationale: Shortens overall "time on air" not only to get the tool on target, but to time to execute functionality and clean-up. - DO NOT perform Disk I/O operations that will cause the system to become unresponsive to the user or alerting to a System Administrator. Now I would just like to note that the other requirements are actually SUPER advanced - the binaries are expected to include complete encryption and decryption, as well as generating completely standard and compliant HTTP traffic that it is wrapped in, under another layer of functionality. There's a ton these binaries do. You will very rarely see requirements similar to what I just quoted in most open source or commercial software. While I realize that when binaries involve active involvement with the user, they will necessarily be a bit more bloated/slower/etc. But most software does not seem to care about being unresponsive, having huge binary sizes, causing CPU spikes, and generally being slow. I don't want you to misunderstand. I am quoting the above requirements for a piece of spyware to show you requirements that are emphatically NOT in any Product Manager's vocabulary. No Product Manager ever seems to tell their programmers to make a tiny, streamlined product that does not cause any unexpected delays or runs like molasses instead of instantly. So I would say that on the whole my hypothesis that slower software is considered objectively better by Product Managers has high plausibility. The fact is, you are already suggesting that if the slower software is evaluated as better than the instant software, it will be "by happenstance." Maybe so - but the fact that product managers choose slowness over speed every day, everywhere, speaks otherwise. Unfortunately I am not in a position to show this scientifically, and also social science experiments are particularly difficult to produce or replicate, with close to half being unreproduceable: http://www.nature.com/news/over-half-of-psychology-studies-fail-reproducibility-test-1.18248 http://www.nature.com/news/over-half-of-psychology-studies-f... "Over half of psychology studies fail reproducibility test". So if you are a product manager, I would just like you to compare the requirements you've ever given out, to the ones I've just quoted (which I consider great requirements.) Of course, I use some minimal programs that meet the description. But as a rule these are programs produced by a single programmer, with no PM in sight. It was nice to talk to you but you seem to view the software landscape differently from how I do. I think it's easy to see that our perspectives are very different.
tedunangst 10y ago
Actually, some software like facial recognition or OCR, does have sleep calls inserted because people don't believe it can be done as fast as it can be done. Thus, whenever I deposit checks at the ATM, I have to stand there and watch as some entirely unnecessary animation pretends to scan my check for ten seconds before I can have my card back.
- gizmo 10y ago
  Yes, the same applies to save buttons. If saving takes less than 200ms people are not confident the save really happened. There are also UI animations that deliberately slow things down to prevent the user from getting disoriented. This doesn't prove that product managers want software to be slow though.
  - tedunangst 10y ago
    Agreed. I think PMs have their own motivations, but ruining things for others is not explicitly part of their grand plan.
    - logicallee 10y ago
      I don't think it's fair of you to switch to the language "ruining things for others" - of course they don't want to explicitly "ruin things". If you had said, "I don't think making sure that things don't happen instantly is explicitly part of their grand plan" then I would dispute that statement. (Yes, making sure things don't happen instantly is explicitly/implicitly part of their grand plan.) They want users to have an "experience" not just click a button or press a key and instantly see the result. It is very explicitly part of their plan, and if the algorithms don't slow things down enough, they actually request animations or loading screens that do so. Some of it may be implicit, rather than explicit. For example, a front-end javascript framework might actually produce pixel for pixel the exact same result as a simple HTML file generated more quickly on the back-end might do, but could still be a preferable "experience". All this could be tested explicitly. For example two groups of PM's could evaluate web sites, where one included Working... screens where a javascript framework slowly renders something client-side, and the other could have pixel-for-pixel the same thing served from the server, using less bandwidth than it took to even transfer the javascript files over, so that the result is served much, much faster. I hereby formally predict that some PM's will prefer the slower version for the exact and only reason that it is a slower user experience, and that this could be verified with a double-blind and carefully controlled experiment. I've put my claim out there, and it is easily falsifiable as well as has explanatory power in terms of the software we actually see. Very simply: some PM's prefer a slower user experience. (I claim.)

by gizmo 10y ago

logicallee 10y ago

>If slowness is the goal and if product managers insist on slowness, then you'd expect a lot of sleep() calls in commercial software (which has product managers) and no sleep() calls in open source software. This doesn't happen. Why do you say this doesn't happen, when it does, in fact, happen? An example of which would be this: http://osxdaily.com/2015/01/06/make-the-window-resizing-animation-speed-instant-in-mac-os-x/ http://osxdaily.com/2015/01/06/make-the-window-resizing-anim... This is a very explicit "sleep". It is far from the only one. Are you saying someone didn't think the slower animation was "better" than the faster animation - that the default time wasn't picked by a product manager? >What we see is that commercial software has better documentation, gets more long term maintenance and support, and supports more cumbersome enterprise features. Exactly what you'd expect when you have salespeople and product managers who talk to customers. We also see fancy loading graphics and I consider it extremely plausible that product managers consider fast/instant operation as room to add something to slow it down. I am not sure why you're debating this. Regarding your open-source claim, this comment - https://news.ycombinator.com/item?id=13940014#13940458 https://news.ycombinator.com/item?id=13940014#13940458 - shows that fancy progress bar animations are considered more important, even in a commandline utility, and even under Linux. In other words, the fact that these progress bar animations slowed core functionality by 50% was -- in point of fact -- not an issue. Someone spent the time to create them, test them, commit them, and these were accepted: someone considered it objectively (or subjectively) better. >Your hypothesis is falsifiable, which is a necessary but not a sufficient condition for it to be scientific. For it to be scientific you would also have to provide evidence that your hypothesis is more plausible than the alternatives, before you do any experiments. You don't think surveying the actual decisions made in cases (such as the two examples just quoted, the window animation speed and the progress bar speed) where there was no functional difference except slowness, to be a plausible reason for supposing that people in charge of these choices choose a slower version? I think it's quite plausible that for whatever reason, slow software is preferred explicitly and implicitly. >After all, it's easy to come up with thousands of silly hypothesis, and by happenstance some of them will get a positive correlation when tested. So every hypothesis has to undergo serious scrutiny. I didn't spend much time looking through it in the original leak (on Wikileaks) but Bruce Schneier quoted on his blog Do's and Don'ts by an intelligence agency: https://www.schneier.com/blog/archives/2017/03/the_cias_develo.html https://www.schneier.com/blog/archives/2017/03/the_cias_deve... The parts I'd like to draw attention to: - DO NOT perform operations that will cause the target computer to be unresponsive to the user (e.g. CPU spikes, screen flashes, screen "freezing", etc). - DO make all reasonable efforts to minimize binary file size for all binaries that will be uploaded to a remote target (without the use of packers or compression). Ideal binary file sizes should be under 150KB for a fully featured tool. Rationale: Shortens overall "time on air" not only to get the tool on target, but to time to execute functionality and clean-up. - DO NOT perform Disk I/O operations that will cause the system to become unresponsive to the user or alerting to a System Administrator. Now I would just like to note that the other requirements are actually SUPER advanced - the binaries are expected to include complete encryption and decryption, as well as generating completely standard and compliant HTTP traffic that it is wrapped in, under another layer of functionality. There's a ton these binaries do. You will very rarely see requirements similar to what I just quoted in most open source or commercial software. While I realize that when binaries involve active involvement with the user, they will necessarily be a bit more bloated/slower/etc. But most software does not seem to care about being unresponsive, having huge binary sizes, causing CPU spikes, and generally being slow. I don't want you to misunderstand. I am quoting the above requirements for a piece of spyware to show you requirements that are emphatically NOT in any Product Manager's vocabulary. No Product Manager ever seems to tell their programmers to make a tiny, streamlined product that does not cause any unexpected delays or runs like molasses instead of instantly. So I would say that on the whole my hypothesis that slower software is considered objectively better by Product Managers has high plausibility. The fact is, you are already suggesting that if the slower software is evaluated as better than the instant software, it will be "by happenstance." Maybe so - but the fact that product managers choose slowness over speed every day, everywhere, speaks otherwise. Unfortunately I am not in a position to show this scientifically, and also social science experiments are particularly difficult to produce or replicate, with close to half being unreproduceable: http://www.nature.com/news/over-half-of-psychology-studies-fail-reproducibility-test-1.18248 http://www.nature.com/news/over-half-of-psychology-studies-f... "Over half of psychology studies fail reproducibility test". So if you are a product manager, I would just like you to compare the requirements you've ever given out, to the ones I've just quoted (which I consider great requirements.) Of course, I use some minimal programs that meet the description. But as a rule these are programs produced by a single programmer, with no PM in sight. It was nice to talk to you but you seem to view the software landscape differently from how I do. I think it's easy to see that our perspectives are very different.

tedunangst 10y ago

Actually, some software like facial recognition or OCR, does have sleep calls inserted because people don't believe it can be done as fast as it can be done. Thus, whenever I deposit checks at the ATM, I have to stand there and watch as some entirely unnecessary animation pretends to scan my check for ten seconds before I can have my card back.

gizmo 10y ago
Yes, the same applies to save buttons. If saving takes less than 200ms people are not confident the save really happened. There are also UI animations that deliberately slow things down to prevent the user from getting disoriented. This doesn't prove that product managers want software to be slow though.
- tedunangst 10y ago
  Agreed. I think PMs have their own motivations, but ruining things for others is not explicitly part of their grand plan.
  - logicallee 10y ago
    I don't think it's fair of you to switch to the language "ruining things for others" - of course they don't want to explicitly "ruin things". If you had said, "I don't think making sure that things don't happen instantly is explicitly part of their grand plan" then I would dispute that statement. (Yes, making sure things don't happen instantly is explicitly/implicitly part of their grand plan.) They want users to have an "experience" not just click a button or press a key and instantly see the result. It is very explicitly part of their plan, and if the algorithms don't slow things down enough, they actually request animations or loading screens that do so. Some of it may be implicit, rather than explicit. For example, a front-end javascript framework might actually produce pixel for pixel the exact same result as a simple HTML file generated more quickly on the back-end might do, but could still be a preferable "experience". All this could be tested explicitly. For example two groups of PM's could evaluate web sites, where one included Working... screens where a javascript framework slowly renders something client-side, and the other could have pixel-for-pixel the same thing served from the server, using less bandwidth than it took to even transfer the javascript files over, so that the result is served much, much faster. I hereby formally predict that some PM's will prefer the slower version for the exact and only reason that it is a slower user experience, and that this could be verified with a double-blind and carefully controlled experiment. I've put my claim out there, and it is easily falsifiable as well as has explanatory power in terms of the software we actually see. Very simply: some PM's prefer a slower user experience. (I claim.)