5 ms·

Because a business report typically doesn't need to be run quickly, it needs to be accurate.

by davesmith1983 7y ago

overcast 7y ago
This type of attitude is what scares me.
- davesmith1983 7y ago
  Your type of attitude scares me. Developers making up arbitrary requirements based on what they want has causes me many a headache.
  - overcast 7y ago
    Sorry, being fast is an arbitrary requirement? That's the entire premise of this article and discussion. The point being that most ARE NOT taking it into consideration and making it one.
    - davesmith1983 7y ago
      I was replying specifically to you wondering why what you consider to be poor performance became the norm. Generally as long as the feature is acceptably fast making it faster is likely a waste of time in most circumstances, especially when it comes to things like reports. Also it may come at the detriment of other considerations e.g cost, accuracy, code quality etc. I used to work on high performance JavaScript and typically the things done in the name of performance make the code a lot harder to read and modify, this pushes up development costs of a feature quite substantially. I haven't seen the stats myself but I doubt it brings in enough extra revenue to justify the cost. I am obviously not saying you shouldn't care about it, but it has to be taken with consideration of the bigger picture.
    - ilikehurdles 7y ago
      > Sorry, being fast is an arbitrary requirement? Yes. In all cases "being fast" is an arbitrary requirement, and a project lead or product manager should when hearing this requirement, interject and ask for a definition of "fast". There are a thousand things at any company that could be done faster than they are. I could throw in eager caching or reindex data into aggregated documents in order to optimize that once-monthly report that takes an hour to generate, or I could automate the other once-monthly report that a group of folks assembles manually for each client. Which one is more valuable to work on? I could rewrite the server in Rust to get a 10ms response time speed up or I could work on the feature that will allow our sales team to be finally able to say "Yes, we do that" to the folks who previously turned us down due to feature parity. I don't live in a world where time is free, or where I can work on all of these things at the same time and still be done in the time it takes to do just one of them. And all that additional logic and caching that could be added to improve the performance of some reports will be an increase of surface area for bugs and data discrepancies, and bring upon the team one of those hardest problems in computer science[1]. [1]:https://www.martinfowler.com/bliki/TwoHardThings.html https://www.martinfowler.com/bliki/TwoHardThings.html
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 ago
  While 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.
chubot 7y ago
I don't believe in that tradeoff, at least from my experience with "business reports". When programs take a long time to run, they take also take a long time to debug. Your edit-run-test cycle is longer. In my experience, programs that are unnecessarily slow are often also unnecessarily buggy. The main reason is that developers don't want to touch them. They rot in the background while the underlying data changes. I'm talking about reports that take hours to run and often don't have any tests. It's pretty easy to get 10x improvement on such programs. This doesn't conflict with the notion that most programs (particularly business reports) don't need to be optimized at all. They just need to be written with some basic understanding of the problem and the underlying platform. Tests go a long way too.
- brokenmachine 7y ago
  >In my experience, programs that are unnecessarily slow are often also unnecessarily buggy. The main reason is that developers don't want to touch them. They rot in the background while the underlying data changes. This is 100% true in my experience.

Because a business report typically doesn't need to be run quickly, it needs to be accurate.

overcast 7y ago

This type of attitude is what scares me.

davesmith1983 7y ago
Your type of attitude scares me. Developers making up arbitrary requirements based on what they want has causes me many a headache.
- overcast 7y ago
  Sorry, being fast is an arbitrary requirement? That's the entire premise of this article and discussion. The point being that most ARE NOT taking it into consideration and making it one.
  - davesmith1983 7y ago
    I was replying specifically to you wondering why what you consider to be poor performance became the norm. Generally as long as the feature is acceptably fast making it faster is likely a waste of time in most circumstances, especially when it comes to things like reports. Also it may come at the detriment of other considerations e.g cost, accuracy, code quality etc. I used to work on high performance JavaScript and typically the things done in the name of performance make the code a lot harder to read and modify, this pushes up development costs of a feature quite substantially. I haven't seen the stats myself but I doubt it brings in enough extra revenue to justify the cost. I am obviously not saying you shouldn't care about it, but it has to be taken with consideration of the bigger picture.
  - ilikehurdles 7y ago
    > Sorry, being fast is an arbitrary requirement? Yes. In all cases "being fast" is an arbitrary requirement, and a project lead or product manager should when hearing this requirement, interject and ask for a definition of "fast". There are a thousand things at any company that could be done faster than they are. I could throw in eager caching or reindex data into aggregated documents in order to optimize that once-monthly report that takes an hour to generate, or I could automate the other once-monthly report that a group of folks assembles manually for each client. Which one is more valuable to work on? I could rewrite the server in Rust to get a 10ms response time speed up or I could work on the feature that will allow our sales team to be finally able to say "Yes, we do that" to the folks who previously turned us down due to feature parity. I don't live in a world where time is free, or where I can work on all of these things at the same time and still be done in the time it takes to do just one of them. And all that additional logic and caching that could be added to improve the performance of some reports will be an increase of surface area for bugs and data discrepancies, and bring upon the team one of those hardest problems in computer science[1]. [1]:https://www.martinfowler.com/bliki/TwoHardThings.html https://www.martinfowler.com/bliki/TwoHardThings.html

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 ago
While 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.

chubot 7y ago

I don't believe in that tradeoff, at least from my experience with "business reports". When programs take a long time to run, they take also take a long time to debug. Your edit-run-test cycle is longer. In my experience, programs that are unnecessarily slow are often also unnecessarily buggy. The main reason is that developers don't want to touch them. They rot in the background while the underlying data changes. I'm talking about reports that take hours to run and often don't have any tests. It's pretty easy to get 10x improvement on such programs. This doesn't conflict with the notion that most programs (particularly business reports) don't need to be optimized at all. They just need to be written with some basic understanding of the problem and the underlying platform. Tests go a long way too.

brokenmachine 7y ago
>In my experience, programs that are unnecessarily slow are often also unnecessarily buggy. The main reason is that developers don't want to touch them. They rot in the background while the underlying data changes. This is 100% true in my experience.