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 a

>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.
      - 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
flukus 10y ago
A lot of places I've worked had government incentives to do this too. Adding features is "R&D" and attracts less payroll tax than optimizing bugs does. Other companies structure themselves this way, a feature is something you can charge to another department, an optimization isn't.
- dbattaglia 10y ago
  I've worked at one place in particular that fell in love with what I call FDD, Finance Driven Development. There's few things more demoralizing than watching systems you helped design fall apart because bug fixes aren't capitalizable.

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

flukus 10y ago

A lot of places I've worked had government incentives to do this too. Adding features is "R&D" and attracts less payroll tax than optimizing bugs does. Other companies structure themselves this way, a feature is something you can charge to another department, an optimization isn't.

dbattaglia 10y ago
I've worked at one place in particular that fell in love with what I call FDD, Finance Driven Development. There's few things more demoralizing than watching systems you helped design fall apart because bug fixes aren't capitalizable.