4 ms·

> Observation #6: Software engineers have been led to believe that their time is more valuable than CPU time; therefore, wasting CPU cycles in order to reduce d

> Observation #6: Software engineers have been led to believe that their time is more valuable than CPU time; therefore, wasting CPU cycles in order to reduce development time is always a win. They've forgotten, however, that the application users' time is more valuable than their time. This is the key thing. I can hardly think of single application where my number one feature request isn’t “make it faster”. Rarely am I interested in a “fresh new look” or “more buttons”. If you can make some task take 5 seconds instead of 10, that is a win for everyone.

pizza234 4y ago
YMMV. I, for example, work in a field where for customers, as long as performance is good enough, features-features-features is the number one priority. Visual Studio Code is actually a good example of "performant enough" software; it's famous (appealing) for its extensibility, but certainly not performance. Then there are cases like Slack or GNOME 3, which were adopted even with lackluster performance. Go figure :|
- TeMPOraL 4y ago
  > I, for example, work in a field where for customers, as long as performance is good enough, features-features-features is the number one priority. There are fields like that. Then there are fields that seem to be like that, but where it's just the person making the purchase decision that cares about "features-features-featues", and actual users don't use most of them and would instead prefer faster software with sane UX. I've definitely seen more of the latter than the former in my life. > Then there are cases like Slack or GNOME 3, which were adopted even with lackluster performance. Go figure :| Nothing to figure out here, it's about who is making the choice, and what choices are available on the market. Slack case is the very common situation of the choice being made by few people (not necessarily best suited for making that choice) for the whole organization / community, and heavily influenced by all the marketing spend and dirty tactics Slack the company did. GNOME 3 is the case of a supplier-driven choice: i.e. some distros defaulted to it for whatever reasons, and people mostly had to accept it, because WM is one but many qualities you care about in a distro, and alone not enough to make you choose a different one. Both types are common situations on the market, and not at all limited to software. To again name them, in short: 1. People making the choice are not the end-users of the product/service. 2. Choice is made by the supplier, and the market doesn't provide an equivalent alternative that made a different choice.
  - osigurdson 4y ago
    >> It's just the person making the purchase decision that cares about "features-features-features" I think it can also be management layer driven. Making something a little bit faster is so much less visible than adding a new, observable / obvious feature.
didgetmaster 4y ago
You also have to multiply time savings by the number of users. If some optimization will cost a developer an hour and that will result in only one minute savings for a single user, then that might seem like a loss; but only if you have less than 60 users. Once your software has a million daily users, every second you save results in a cumulative savings of 1 million seconds (over 11 days).

pizza234 4y ago

YMMV. I, for example, work in a field where for customers, as long as performance is good enough, features-features-features is the number one priority. Visual Studio Code is actually a good example of "performant enough" software; it's famous (appealing) for its extensibility, but certainly not performance. Then there are cases like Slack or GNOME 3, which were adopted even with lackluster performance. Go figure :|

TeMPOraL 4y ago
> I, for example, work in a field where for customers, as long as performance is good enough, features-features-features is the number one priority. There are fields like that. Then there are fields that seem to be like that, but where it's just the person making the purchase decision that cares about "features-features-featues", and actual users don't use most of them and would instead prefer faster software with sane UX. I've definitely seen more of the latter than the former in my life. > Then there are cases like Slack or GNOME 3, which were adopted even with lackluster performance. Go figure :| Nothing to figure out here, it's about who is making the choice, and what choices are available on the market. Slack case is the very common situation of the choice being made by few people (not necessarily best suited for making that choice) for the whole organization / community, and heavily influenced by all the marketing spend and dirty tactics Slack the company did. GNOME 3 is the case of a supplier-driven choice: i.e. some distros defaulted to it for whatever reasons, and people mostly had to accept it, because WM is one but many qualities you care about in a distro, and alone not enough to make you choose a different one. Both types are common situations on the market, and not at all limited to software. To again name them, in short: 1. People making the choice are not the end-users of the product/service. 2. Choice is made by the supplier, and the market doesn't provide an equivalent alternative that made a different choice.
- osigurdson 4y ago
  >> It's just the person making the purchase decision that cares about "features-features-features" I think it can also be management layer driven. Making something a little bit faster is so much less visible than adding a new, observable / obvious feature.

didgetmaster 4y ago

You also have to multiply time savings by the number of users. If some optimization will cost a developer an hour and that will result in only one minute savings for a single user, then that might seem like a loss; but only if you have less than 60 users. Once your software has a million daily users, every second you save results in a cumulative savings of 1 million seconds (over 11 days).