Unfortunately devs invest in the fastest equiplent, so they don't experience how their code runs on the average end user who doesn't upgrade every couple years.
In can be useful to test your code in a VM that is deliberately slowed down, so can get a feel for user experience on a slower machine. Then you'll know what parts need to be optimized.
It'll be pretty clear if some change you've made is going to impact people on older hardware, because you'll notice the moment you make the change. And if it's unbearably slow for you, it will be for a good chunk of your users as well.
As someone who doesn't spend much on computer upgrades, I notice this everywhere. Especially when it comes to web development, where everything is optimized for chrome on mac. Don't have a laptop made in the last year? Enjoy a janky-scrolling slow-loading hard-to-read mess.
If you gave that to a Product Manager candidate (as part of an interview) and pretended it's your current product (assume they didn't know it already), asked them to play around with it for ten minutes and as their task come up with some thoughts regarding what they would add or improve, their eyes would pop open and they would say, "WOWWW!! THIS LOOKS LIKE IT ISN'T DOING ANYTHING -- THERE IS A LOT OF ROOM FOR IMPROVEMENT HERE."
And in just fifteen minutes, they would gleefully tell you exactly how they would break it. (By adding crap to make it slow.)
(Note: this could be run as a real experiment, but the results above are my personal prediction - maybe it wouldn't happen as I predict.)
I really do think product managers are the people to blame here. To them, fast = broken or not doing anything. It's not done (to them) until it's (to us) broken.
Like, I want the experiment to test if a product isn't already slow, would a product manager actively make it slow? (I think, "yes".)
So the hypothesis is that if it's too fast it's not considered done by a product manager. So as an updated test protocol, let us repeat with two groups of Product Managers, and this time they must evaluate the software, which they have never used before. Some candidates get the older version on the metal, and others get the older version slowed down 10x for example by running in a VM on the test machine, or simply being shown to them running on older hardware but otherwise an identical setup.
My hypothesis is that the exact same software running slowly would be objectively judged as better by Product Managers than the same software running instantly. That instant execution is considered an explicit negative point - completely independent of features. So that if the old software running slowly gets 7.5/10 rating by the Product Managers asked to evauate it, it would get only a 5/10 rating if it runs instantly.
This controls for the features which you mention. So I've suggested a test protocol, of course I can't verify it just at this moment but at least I am being scientific in my suggestion that Product Managers simply rate fast software worse. If you have an alternative protocol to test this, one that is easier to run, I'd like to hear it.
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.
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.
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.)
When you do get to use it, using performant software is a really great experience, so how to we train users to appreciate this?
Ditto BitTorrent clients like uTorrent and Transmission; the first generation of BitTorrent clients were written in Python or Java, and felt like it. When users started complaining about how they would lock up your machine, somebody actually bothered to write one in highly-optimized native Win32 C, with no frameworks.
You have to understand what the customer is optimizing for though. Someone standing at an ATM is optimizing for confidence, not speed; they already took the time to drive to the ATM, so depositing their check in 1 second vs. 10 seconds doesn't matter when the whole trip takes them 10 minutes. Someone who's responsible for depositing 1000s of checks for a major business, using an office scanner, cares a lot. But I really doubt that industrial-strength check cashing apps put a sleep() statement when scanning the checks.
I highly doubt the ATM maker put in sleep calls to intentionally slow it down -- no one is going to be surprised if it takes 1 second instead of 10 seconds to scan a check.
The bank could optimize for time, but it's not their time, it's their customer's time and they are already saving so much money over a teller transaction, they likely don't care about saving customers a few seconds.