5 ms·

I guess its an interesting difference right - what say a developer would consider "instant" (lets say <10ms) and what the end user is satisfied with as instant

I guess its an interesting difference right - what say a developer would consider "instant" (lets say <10ms) and what the end user is satisfied with as instant (maybe <1min)...it's interesting the tradeoffs you can make when you loosen your latency requirements.

adrianN 10y ago
Thinking like this leads to products like Rational Doors, a requirements database where searching is dog slow and you need to know where to look if you want to find anything.
- windowsworkstoo 10y ago
  Really? I've no idea what that product is but I hardly think it's a "thinking" problem, more a managing expectation or shit requirements gathering problem. If it was necessary to search in a certian way over a certain size in a certain time, you could make the appropriate trade off. Sounds like you just wanted to bitch out about a particular product pal.
  - adrianN 10y ago
    I admit I like bitching about slow software. But if you don't put speed as one of your top requirements, over time your software will become slower and slower. Having one operation that takes 100ms instead of 10ms is fine until two years later when somebody else who doesn't bother to read your code uses it to implement something that now takes one second instead of 100ms, which is incidentally used a hundred times to complete some query that now takes minutes instead of seconds. Now imagine you're a company like IBM or SAP that works on the same code base for decades and the cruft keeps layering and layering until even finding out which part of the code needs to be tuned becomes too expensive to explain to your customers. There is http://accidentallyquadratic.tumblr.com http://accidentallyquadratic.tumblr.com with a nice collection of "it was fast enough at the time" code.
    - mnkmnk 10y ago
      Why would it be difficult to profile and find the bottleneck after a few decades? It should actually be even easier with better profiling tools and practices.
      - adrianN 10y ago
        Uniformly shitty code is hard to profile. See for example what Chandler has to say about writing good code https://www.youtube.com/watch?v=fHNmRkzxHWs https://www.youtube.com/watch?v=fHNmRkzxHWs
    - to3m 10y ago
      There's an explanatory post there that in particular is very much worth reading: http://accidentallyquadratic.tumblr.com/post/113840433022/why-accidentally-quadratic http://accidentallyquadratic.tumblr.com/post/113840433022/wh...
halomru 10y ago
>what the end user is satisfied with as instant (maybe <1min). There's a number of thresholds you can hit: 5 minutes: this is taking a while, better grab a coffee 1 minute: this is taking a while, I can let my thoughts drift a bit 10 seconds: it will be done soon, I'll just stare at the screen till it's done 1 second: it's not slow, but sluggish and interrupting my flow 200 milliseconds: that result came instantly when I pressed the button 50 milliseconds: the results update instantly when I use this slider Hitting another of these milestones transforms the user experience and allows the dataset to be experienced in a new way, allowing more spontaneous exploration of the data

adrianN 10y ago

Thinking like this leads to products like Rational Doors, a requirements database where searching is dog slow and you need to know where to look if you want to find anything.

windowsworkstoo 10y ago
Really? I've no idea what that product is but I hardly think it's a "thinking" problem, more a managing expectation or shit requirements gathering problem. If it was necessary to search in a certian way over a certain size in a certain time, you could make the appropriate trade off. Sounds like you just wanted to bitch out about a particular product pal.
- adrianN 10y ago
  I admit I like bitching about slow software. But if you don't put speed as one of your top requirements, over time your software will become slower and slower. Having one operation that takes 100ms instead of 10ms is fine until two years later when somebody else who doesn't bother to read your code uses it to implement something that now takes one second instead of 100ms, which is incidentally used a hundred times to complete some query that now takes minutes instead of seconds. Now imagine you're a company like IBM or SAP that works on the same code base for decades and the cruft keeps layering and layering until even finding out which part of the code needs to be tuned becomes too expensive to explain to your customers. There is http://accidentallyquadratic.tumblr.com http://accidentallyquadratic.tumblr.com with a nice collection of "it was fast enough at the time" code.
  - mnkmnk 10y ago
    Why would it be difficult to profile and find the bottleneck after a few decades? It should actually be even easier with better profiling tools and practices.
    - adrianN 10y ago
      Uniformly shitty code is hard to profile. See for example what Chandler has to say about writing good code https://www.youtube.com/watch?v=fHNmRkzxHWs https://www.youtube.com/watch?v=fHNmRkzxHWs
  - to3m 10y ago
    There's an explanatory post there that in particular is very much worth reading: http://accidentallyquadratic.tumblr.com/post/113840433022/why-accidentally-quadratic http://accidentallyquadratic.tumblr.com/post/113840433022/wh...

halomru 10y ago

>what the end user is satisfied with as instant (maybe <1min). There's a number of thresholds you can hit: 5 minutes: this is taking a while, better grab a coffee 1 minute: this is taking a while, I can let my thoughts drift a bit 10 seconds: it will be done soon, I'll just stare at the screen till it's done 1 second: it's not slow, but sluggish and interrupting my flow 200 milliseconds: that result came instantly when I pressed the button 50 milliseconds: the results update instantly when I use this slider Hitting another of these milestones transforms the user experience and allows the dataset to be experienced in a new way, allowing more spontaneous exploration of the data