>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-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 - 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_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-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.