3 ms·
Sure, it needs to be accurate, but why can't it be quick too? Unless it's truly cost-prohibitive, quick is always a better user experience.
by zeroxfe 7y ago
Sure, it needs to be accurate, but why can't it be quick too? Unless it's truly cost-prohibitive, quick is always a better user experience.
- deleted 7y ago[deleted]
- cosmodisk 7y agoWhile I'm a strong advocate of speedy software, fast doesn't always mean better than reliable. The points raised in the comments above are valid: if a legal team needs a report once a month and it takes a day to return the results but is super accurate, that's almost always a preferred choice over something quick but less reliable. There are a lot of comments on this thread but a lot of them lack context: yes,maybe it takes ages to run a query,but what's behind the scenes? Does it do some fancy shpancy, mission critical calculations or simply returning results from a database with 10K records.
- TeMPOraL 7y ago> Does it do some fancy shpancy, mission critical calculations or simply returning results from a database with 10K records. Or does it do something stupid, like manipulating a fixed but large amounts of data in a linked list, looking up in a linked list instead of a hash table, and/or passing lots of stuff up and down 20 layers of dependency-injected abstractions? In my (arguably relatively brief) career, I've seen multiple cases where the core limit on product performance was something stupid that could be trivially identified with a profiler and could yield overall 10x boost of performance. Despite complaints from users, nobody really bothered to fix it.