4 ms·

And he's not even talking about software bloat. The word processor I have on my early 90's Powerbook is more responsive, generally faster to use, than my curren

And he's not even talking about software bloat. The word processor I have on my early 90's Powerbook is more responsive, generally faster to use, than my current one running on a Core 2 duo processor. Oh, and by the way, I was once complaining about this to a friend who's in IT, and he told me how the speed in which a software runs doesn't mean anything regarding its quality. What I mean is, I was telling him how bad some new software was because it was quite slower than one 10 years older which did the same thing, and he tolde me that, in software engineering, this (speed) is never a measure of a program's quality. Is this universally accepted? Speed and responsiveness are not taken into account? I always meant to ask other people in this field, but always forgot.

TeMPOraL 7y ago
> Oh, and by the way, I was once complaining about this to a friend who's in IT, and he told me how the speed in which a software runs doesn't mean anything regarding its quality. Your friend is wrong. It's an imperfect proxy, but looking at programs that do work, speed is a good proxy for quality, because speed means someone gives a damn. There are good programs that are slow, but bad programs all tend to be bloated. Of course "speed" is something to be evaluated in context. In a group of e.g. 3D editors, a more responsive UI suggests a better editor. A more responsive UI in general suggests a better program in general. > this (speed) is never a measure of a program's quality. Is this universally accepted? Universally? No. It all depends on who you ask. Companies tend to say speed isn't, but the truth is, a lot of companies today don't care about quality at all - it's not what sells software. If you ask users, you'll get mixed answers, depending on whether the software they use often is slow enough to anger them regularly.
PavlovsCat 7y ago
> he tolde me that, in software engineering, this (speed) is never a measure of a program's quality Never? That's just wrong. It may not always matter that much, but generally, all else being equal, faster is always better, because "speed" in this context mostly means few wasted cycles. Consider two people going to the store. One runs to the store and back, the other person runs towards the store at the same speed, but halfway through, they remember they forgot something at home, and fetch it. They repeat that so often, it takes them 2 days to go to the store, or even weeks. A CPU will do whatever nonsense it is instructed to do, at breakneck pace, as long as there is electricity to do it with. There is no contest what is "better" in some cases, and devs cutting corners (ironically leading to slower programs) are externalizing the costs of that to their users. Sometimes that can be justified, but when people don't even know the trade-offs they are making, that is a problem.
clarry 7y ago
More like speed is a quality, whether you care about it or not is a different story. In many cases I'm happy with simple but slow but fast enough.
joshspankit 7y ago
To me (on the internet since 92), speed is 100% a measure of a program’s quality. Intensive tasks get a pass (especially if they are pushed to a background queue), but IU responsiveness is definitely a measure of quality for me. Jason Fried has also written an optimized extensively for UI speed in Basecamp (a quick google shows an article from 2008). Speaking of: there has also been a lot written about Amazon’s discovery that every 100ms of latency cost them 1% of sales from people simply walking away from the “slow” site. Especially when you’re doing the same task “template” on a day to day basis, even 1 second per input adds up quickly.
tripzilch 7y ago
One reason why I'm happy to not be in IT, is because of said bullshit. Maybe that means I am part of the problem, because if every programmer who has a problem with that, leaves, you're left with just the programmers like your friend who don't see anything wrong with this.

TeMPOraL 7y ago

> Oh, and by the way, I was once complaining about this to a friend who's in IT, and he told me how the speed in which a software runs doesn't mean anything regarding its quality. Your friend is wrong. It's an imperfect proxy, but looking at programs that do work, speed is a good proxy for quality, because speed means someone gives a damn. There are good programs that are slow, but bad programs all tend to be bloated. Of course "speed" is something to be evaluated in context. In a group of e.g. 3D editors, a more responsive UI suggests a better editor. A more responsive UI in general suggests a better program in general. > this (speed) is never a measure of a program's quality. Is this universally accepted? Universally? No. It all depends on who you ask. Companies tend to say speed isn't, but the truth is, a lot of companies today don't care about quality at all - it's not what sells software. If you ask users, you'll get mixed answers, depending on whether the software they use often is slow enough to anger them regularly.

PavlovsCat 7y ago

> he tolde me that, in software engineering, this (speed) is never a measure of a program's quality Never? That's just wrong. It may not always matter that much, but generally, all else being equal, faster is always better, because "speed" in this context mostly means few wasted cycles. Consider two people going to the store. One runs to the store and back, the other person runs towards the store at the same speed, but halfway through, they remember they forgot something at home, and fetch it. They repeat that so often, it takes them 2 days to go to the store, or even weeks. A CPU will do whatever nonsense it is instructed to do, at breakneck pace, as long as there is electricity to do it with. There is no contest what is "better" in some cases, and devs cutting corners (ironically leading to slower programs) are externalizing the costs of that to their users. Sometimes that can be justified, but when people don't even know the trade-offs they are making, that is a problem.

clarry 7y ago

More like speed is a quality, whether you care about it or not is a different story. In many cases I'm happy with simple but slow but fast enough.

joshspankit 7y ago

To me (on the internet since 92), speed is 100% a measure of a program’s quality. Intensive tasks get a pass (especially if they are pushed to a background queue), but IU responsiveness is definitely a measure of quality for me. Jason Fried has also written an optimized extensively for UI speed in Basecamp (a quick google shows an article from 2008). Speaking of: there has also been a lot written about Amazon’s discovery that every 100ms of latency cost them 1% of sales from people simply walking away from the “slow” site. Especially when you’re doing the same task “template” on a day to day basis, even 1 second per input adds up quickly.

tripzilch 7y ago

One reason why I'm happy to not be in IT, is because of said bullshit. Maybe that means I am part of the problem, because if every programmer who has a problem with that, leaves, you're left with just the programmers like your friend who don't see anything wrong with this.