5 ms·

An eye-opening experience is running an IDE like Visual Studio 6 or a really old version of Photoshop on a modern machine. It starts instantly, compile times ar

by gizmo 10y ago

An eye-opening experience is running an IDE like Visual Studio 6 or a really old version of Photoshop on a modern machine. It starts instantly, compile times are a fraction of what we're used to. The interface is totally responsive. It's remarkable how much better software feels when everything is instant.

userbinator 10y ago
Developer tools like Visual Studio are somewhat ironic in that the developers who create inefficient software are essentially seeing this reflected indirectly in their tools also becoming inefficient. A perverse version of "do unto others as you would have them do unto you"?
- agumonkey 10y ago
  I used to think that of the java world. It wasn't above some critical mass / threshold of simplicity, and everybody that liked java lacked that simplicity, and every solutions they tried to add to java just added more cruft (xml, j2ee beans, IDEs)
logicallee 10y ago
>An eye-opening experience is running an IDE like Visual Studio 6 or a really old version of Photoshop on a modern machine. It starts instantly, compile times are a fraction of what we're used to. The interface is totally responsive. 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.
- tedunangst 10y ago
  Or start with the current version, then demo the ancient version, and claim you've "streamlined and tuned" the program?
  - logicallee 10y ago
    What I was getting at is that the suggestions to add crap would come from the product manager candidate themselves - thereby "proving" (if the results match my prediction) that the requirement for slow unresponsive interfaces come directly from the PM's, who would add it if it weren't already slow. 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".)
    - gizmo 10y ago
      When software is too slow it hurts sales. When software lacks features that hurts sales too. Faster doesn't make for compelling marketing (anybody can claim their software is fast) but you can get people to upgrade for new features. So features are added with every release and performance improvements are made up so to the point where it's "good enough" again. You don't need a product manager conspiracy to explain why software is bloated and slow.
      - logicallee 10y ago
        Okay, so let's update the experiment protocol. 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.
bcook 10y ago
Similarly, I run a very barebones Openbox Arch Linux install on my ancient 2Ghz Turion 64 laptop and I recently booted Windows XP on it and I was blown away by how fluid & responsive the entire system was compared to my much newer Linux-based OS.
- agumonkey 10y ago
  Also, surprisingly, XP could handle 64MB decently (even for a nazi like me)
  - flukus 10y ago
    My memory is very blurred, but I thought 32MB (maybe less) was still pretty standard when XP came out.
em3rgent0rdr 10y ago
It's remarkable how much better software feels when the software was developed on a slow machine. 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.
- megablast 10y ago
  Unfortunately devs aren't given any time to optimise it to run on slow machines. It is not a priority.
  - ryukafalz 10y ago
    You don't necessarily need to specifically optimize for it: just do your development on a slower machine. If you're using a compiled language, you can offload compilation with something like distcc for productivity's sake, but all your testing should be on the slow machine. 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.
- Gracana 10y ago
  > 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. 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.
  - snackai 10y ago
    Also, the web devs have no idea how slow the connections in even the western world can be. At least I think so, if they had to experience a 4 Mbit/s connection more often they wouldn't push for Angular and such.

by gizmo 10y ago

userbinator 10y ago

Developer tools like Visual Studio are somewhat ironic in that the developers who create inefficient software are essentially seeing this reflected indirectly in their tools also becoming inefficient. A perverse version of "do unto others as you would have them do unto you"?

agumonkey 10y ago
I used to think that of the java world. It wasn't above some critical mass / threshold of simplicity, and everybody that liked java lacked that simplicity, and every solutions they tried to add to java just added more cruft (xml, j2ee beans, IDEs)

logicallee 10y ago

>An eye-opening experience is running an IDE like Visual Studio 6 or a really old version of Photoshop on a modern machine. It starts instantly, compile times are a fraction of what we're used to. The interface is totally responsive. 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.

tedunangst 10y ago
Or start with the current version, then demo the ancient version, and claim you've "streamlined and tuned" the program?
- logicallee 10y ago
  What I was getting at is that the suggestions to add crap would come from the product manager candidate themselves - thereby "proving" (if the results match my prediction) that the requirement for slow unresponsive interfaces come directly from the PM's, who would add it if it weren't already slow. 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".)
  - gizmo 10y ago
    When software is too slow it hurts sales. When software lacks features that hurts sales too. Faster doesn't make for compelling marketing (anybody can claim their software is fast) but you can get people to upgrade for new features. So features are added with every release and performance improvements are made up so to the point where it's "good enough" again. You don't need a product manager conspiracy to explain why software is bloated and slow.
    - logicallee 10y ago
      Okay, so let's update the experiment protocol. 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.

bcook 10y ago

Similarly, I run a very barebones Openbox Arch Linux install on my ancient 2Ghz Turion 64 laptop and I recently booted Windows XP on it and I was blown away by how fluid & responsive the entire system was compared to my much newer Linux-based OS.

agumonkey 10y ago
Also, surprisingly, XP could handle 64MB decently (even for a nazi like me)
- flukus 10y ago
  My memory is very blurred, but I thought 32MB (maybe less) was still pretty standard when XP came out.

em3rgent0rdr 10y ago

It's remarkable how much better software feels when the software was developed on a slow machine. 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.

megablast 10y ago
Unfortunately devs aren't given any time to optimise it to run on slow machines. It is not a priority.
- ryukafalz 10y ago
  You don't necessarily need to specifically optimize for it: just do your development on a slower machine. If you're using a compiled language, you can offload compilation with something like distcc for productivity's sake, but all your testing should be on the slow machine. 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.
Gracana 10y ago
> 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. 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.
- snackai 10y ago
  Also, the web devs have no idea how slow the connections in even the western world can be. At least I think so, if they had to experience a 4 Mbit/s connection more often they wouldn't push for Angular and such.