4 ms·

Why do we care so much about the dev? There are way more people who use a typical program than there are people who develop it, and these people often use the

by panic 10y ago

Why do we care so much about the dev? There are way more people who use a typical program than there are people who develop it, and these people often use the program more frequently than the developers make changes to it. For example, if a feature is used every day for a year by 10,000 people, speeding it up by 200ms is worth over a month of developer time (200ms for 10,000 people over a year is 203 hours of time wasted, which is about 25 8-hour days, or five 40-hour weeks).

BHSPitMonkey 10y ago
Who is funding the developer? Why should they spend $5k (plus the opportunity cost of not using that dev's time on more fruitful pursuits) on 2 weeks of micro-optimization so that their 10,000 users will each experience a speedup so small they'll never even notice (and certainly never pay extra for)? How do you justify that expense?
- panic 10y ago
  I'm making a more abstract argument that doesn't have anything to do with money. The time people spend using a piece of software shouldn't be worth less than the time developers spend writing it.
  - BHSPitMonkey 10y ago
    Okay, but under those conditions your argument can only be applied to a more abstract reality that isn't the one we actually live our lives in.
  - nemothekid 10y ago
    The time developers spend writing a piece of software is worth what people are willing to pay for it. It has everything to do with money - if the person using the software isn't willing to spend more for 200ms less in startup latency, it probably won't happen.
- flukus 10y ago
  > How do you justify that expense? It makes it harder for your competitors to offer a better product.
- mrob 10y ago
  200ms delay is easily noticeable. Even 50ms is noticeable. And latency is cumulative, and your user's hardware already adds some, so you never know exactly how much latency budget you have before the whole system feels unpleasant. I think 25ms is a reasonable goal, and even 10ms wouldn't be a waste of effort. All interactive software should be written like a fast-paced action game.
buzzybee 10y ago
This equation starts with 0 users and grows pretty slowly at first. It only flips once you have a critical mass of users, and by then it's "too late" to preventatively fix the architecture to bias to performance. There are also lots and lots of products that take a "npm+glue" approach - they ship an initial version that leverages everything possible, and then run aground trying to make it to version 2, because the architecture is so reliant on the dependencies that it can neither be maintained nor support any additional features. This is a little bit different from the "Electron problem" in that it identifies a showstopper limitation to using developer-side easings, rather than a long-term paper cut issue.
- panic 10y ago
  This equation starts with 0 users and grows pretty slowly at first. It only flips once you have a critical mass of users, and by then it's "too late" to preventatively fix the architecture to bias to performance. Sure, but everyone's always planning for the future when they choose databases, backend architecture, etc. Why not plan for the future in user experience, too?
  - photojosh 10y ago
    Keeping I'm mind the things I've developed are niche and not large; a dozen users at one time is about as far as I've got.... With databases, I use SQLite for quick prototyping and single user apps, and Postgres for the multi-user ones. If I needed to scale, I'd optimise my queries better and consult an expert. With backend architecture, I'm most experienced with Python, Django & Twisted. I know these are used in web-scale apps, so if I needed to scale, I'd once again optimise best I could and consult an expert. Now, UI is a different kind of scaling problem, because ideally it's going to look and interact the same for 10 users as it does for a million. You're scaling based on the features you add as opposed to the number of users. How do you scale that? I'd say it's just as is happening now; you rewrite the UI as you scale, because if your revenue grows with users, you can afford to. On mobile devices: web page -> mobile app with mainly HTML views -> full native UI. On desktop: background server + webpage (think Plex) -> Electron/web-tech-based app -> full native app. The problem ends up being when your revenue is independent from number of users and you don't have the resources to do the rewrites. Or as is likely the case with apps such as Atom; a big part of your proposition is the availability of plugins from third-parties.
pilom 10y ago
Pretty obviously, not all time is equal in the eyes of the company that owns the software. That month of dev time costs on the order of $10k-20k all it where the users time is free from their perspective.
jsudhams 10y ago
Only if those 10000 people do something else in that 200ms and also if they multitask it does not matter. Except in some HFT or other specific use cases, i dont think even 100000 will matter 200ms fix.
stymaar 10y ago
> For example, if a feature is used every day for a year by 10,000 people, speeding it up by 200ms is worth over a month of developer time (200ms for 10,000 people over a year is 203 hours of time wasted, which is about 25 8-hour days, or five 40-hour weeks). Is your company ready to pay $10-20k to its software supplier to save 200ms per person ? Rationally it may be a good idea, but I sincerely doubt anybody would pay for that.
- kedean 10y ago
  You can't reduce it to those simple variables, though. What if the speedup is enough to remove multiple AWS servers, saving potentially thousands of dollars per year moving forward? What if those milliseconds are the ones that keep more users on your site, like in Amazon's famous search bar story?

by panic 10y ago

BHSPitMonkey 10y ago

Who is funding the developer? Why should they spend $5k (plus the opportunity cost of not using that dev's time on more fruitful pursuits) on 2 weeks of micro-optimization so that their 10,000 users will each experience a speedup so small they'll never even notice (and certainly never pay extra for)? How do you justify that expense?

panic 10y ago
I'm making a more abstract argument that doesn't have anything to do with money. The time people spend using a piece of software shouldn't be worth less than the time developers spend writing it.
- BHSPitMonkey 10y ago
  Okay, but under those conditions your argument can only be applied to a more abstract reality that isn't the one we actually live our lives in.
- nemothekid 10y ago
  The time developers spend writing a piece of software is worth what people are willing to pay for it. It has everything to do with money - if the person using the software isn't willing to spend more for 200ms less in startup latency, it probably won't happen.
flukus 10y ago
> How do you justify that expense? It makes it harder for your competitors to offer a better product.
mrob 10y ago
200ms delay is easily noticeable. Even 50ms is noticeable. And latency is cumulative, and your user's hardware already adds some, so you never know exactly how much latency budget you have before the whole system feels unpleasant. I think 25ms is a reasonable goal, and even 10ms wouldn't be a waste of effort. All interactive software should be written like a fast-paced action game.

buzzybee 10y ago

This equation starts with 0 users and grows pretty slowly at first. It only flips once you have a critical mass of users, and by then it's "too late" to preventatively fix the architecture to bias to performance. There are also lots and lots of products that take a "npm+glue" approach - they ship an initial version that leverages everything possible, and then run aground trying to make it to version 2, because the architecture is so reliant on the dependencies that it can neither be maintained nor support any additional features. This is a little bit different from the "Electron problem" in that it identifies a showstopper limitation to using developer-side easings, rather than a long-term paper cut issue.

panic 10y ago
This equation starts with 0 users and grows pretty slowly at first. It only flips once you have a critical mass of users, and by then it's "too late" to preventatively fix the architecture to bias to performance. Sure, but everyone's always planning for the future when they choose databases, backend architecture, etc. Why not plan for the future in user experience, too?
- photojosh 10y ago
  Keeping I'm mind the things I've developed are niche and not large; a dozen users at one time is about as far as I've got.... With databases, I use SQLite for quick prototyping and single user apps, and Postgres for the multi-user ones. If I needed to scale, I'd optimise my queries better and consult an expert. With backend architecture, I'm most experienced with Python, Django & Twisted. I know these are used in web-scale apps, so if I needed to scale, I'd once again optimise best I could and consult an expert. Now, UI is a different kind of scaling problem, because ideally it's going to look and interact the same for 10 users as it does for a million. You're scaling based on the features you add as opposed to the number of users. How do you scale that? I'd say it's just as is happening now; you rewrite the UI as you scale, because if your revenue grows with users, you can afford to. On mobile devices: web page -> mobile app with mainly HTML views -> full native UI. On desktop: background server + webpage (think Plex) -> Electron/web-tech-based app -> full native app. The problem ends up being when your revenue is independent from number of users and you don't have the resources to do the rewrites. Or as is likely the case with apps such as Atom; a big part of your proposition is the availability of plugins from third-parties.

pilom 10y ago

Pretty obviously, not all time is equal in the eyes of the company that owns the software. That month of dev time costs on the order of $10k-20k all it where the users time is free from their perspective.

jsudhams 10y ago

Only if those 10000 people do something else in that 200ms and also if they multitask it does not matter. Except in some HFT or other specific use cases, i dont think even 100000 will matter 200ms fix.

stymaar 10y ago

> For example, if a feature is used every day for a year by 10,000 people, speeding it up by 200ms is worth over a month of developer time (200ms for 10,000 people over a year is 203 hours of time wasted, which is about 25 8-hour days, or five 40-hour weeks). Is your company ready to pay $10-20k to its software supplier to save 200ms per person ? Rationally it may be a good idea, but I sincerely doubt anybody would pay for that.

kedean 10y ago
You can't reduce it to those simple variables, though. What if the speedup is enough to remove multiple AWS servers, saving potentially thousands of dollars per year moving forward? What if those milliseconds are the ones that keep more users on your site, like in Amazon's famous search bar story?