4 ms·

you said you work in a corporate context, right? let's take an example that's not too far-fetched: legal comes and says that every month, you need to generate

you said you work in a corporate context, right? let's take an example that's not too far-fetched: legal comes and says that every month, you need to generate an report of some sort to comply with some regulation that corporations over a certain size must comply with. you sit down and run v1 of the software which works but takes 24 hours to run. is your first instinct to get infuriated, as you said, even though from a requirements/company perspective, this is completely "done right"? "the issue" is that changing software involves risks, which may be acceptable to you, but may not be acceptable to e.g. legal. they couldn't care less if it took 29 days to run or 29 ms. what they require - again, this is the requirement - is a monthly report generated, correctly. and yeah, 99 times out of 100 you change the SQL correctly and it runs in 1/1000 of the time the first time. then for whatever reason it messes up one month and legal asks "what the F was this guy doing mucking around with this software which worked 'right'"?

overcast 7y ago
I'll give you some real corporate context. A scheduled task, pulling from a 65GB table with hundred of millions of rows, and no indexes. It runs for hours, and completes with accurate data. During that time, it also saturated a 10Gbit interface(seriously), and consumed half of the IOPS on one our NetApp controllers. Now multiply that by 2x, 10x, 1000x for all of the other junk running in the wild. Slow, accurate, and impacting the rest of the organization.
wiz21c 7y ago
i.e; premature optimization is root of all evil . The example you give is sooo right. And understanding the many levels of compromise between code speed, quality, legal implications, customer needs, management needs, cost, deadline, maintainability, technological choices made elsewhere, etc. is part of the job. (personally, I have some priorities : meet the deadline comes first (descoping included), management at customer side comes next, then end users and, in the end code speed.
- TeMPOraL 7y ago
  > i.e; premature optimization is root of all evil I'm gonna repost a chart I made previously[0]: Spectrum of performance: LO |---*-------*--------*------------*-------| HI ^ ^ ^ ^ | | | |_root of all evil if premature | | |_you should be here | |_you can be here if you don't do stupid things |_you are here Point being, people tend to invoke this cliche way too early. It's true that mucking with working software is a potentially risky thing, and in corporate context may require approval, but it's also kind of the job you're hired to do as a software engineer, and it's especially important if that extra efficiency buys company value. -- [0] - https://news.ycombinator.com/item?id=20389856 https://news.ycombinator.com/item?id=20389856
  - ghettoimp 7y ago
    > it's especially important if that extra efficiency buys company value. If you've figured out that this is the case, the optimization is no longer premature.
    - hinkley 7y ago
      I can't recall the last time I heard someone say "premature optimization is root of all evil" as a sanity check to someone who was overdoing things. In fact it may have been more than 20 years ago. For one, there are usually better arguments around code comprehension. Pretty much the only time I hear this statement is as a response to criticism. That should raise some questions about the motivations of the speaker. Quite often it comes off as a dodge, and why and what are they dodging? Additionally, the whole quote is often at odds with the point the speaker is trying to make. It's not small inefficiencies, it's factors of 5, or 10, or an extra 6 months before we run out of headroom on something.
  - hinkley 7y ago
    > premature optimization is root of all evil Aka the first refuge of the intellectually lazy.
    - 7y ago
HelloNurse 7y ago
A competent and responsible programmer should know how good, on a scale from cheaply done prototype to provably optimal, the 24-hour report is. In the first case, rewriting for better performance is part of the first implementation, not a risky change.

overcast 7y ago

I'll give you some real corporate context. A scheduled task, pulling from a 65GB table with hundred of millions of rows, and no indexes. It runs for hours, and completes with accurate data. During that time, it also saturated a 10Gbit interface(seriously), and consumed half of the IOPS on one our NetApp controllers. Now multiply that by 2x, 10x, 1000x for all of the other junk running in the wild. Slow, accurate, and impacting the rest of the organization.

wiz21c 7y ago

i.e; premature optimization is root of all evil . The example you give is sooo right. And understanding the many levels of compromise between code speed, quality, legal implications, customer needs, management needs, cost, deadline, maintainability, technological choices made elsewhere, etc. is part of the job. (personally, I have some priorities : meet the deadline comes first (descoping included), management at customer side comes next, then end users and, in the end code speed.

TeMPOraL 7y ago
> i.e; premature optimization is root of all evil I'm gonna repost a chart I made previously[0]: Spectrum of performance: LO |---*-------*--------*------------*-------| HI ^ ^ ^ ^ | | | |_root of all evil if premature | | |_you should be here | |_you can be here if you don't do stupid things |_you are here Point being, people tend to invoke this cliche way too early. It's true that mucking with working software is a potentially risky thing, and in corporate context may require approval, but it's also kind of the job you're hired to do as a software engineer, and it's especially important if that extra efficiency buys company value. -- [0] - https://news.ycombinator.com/item?id=20389856 https://news.ycombinator.com/item?id=20389856
- ghettoimp 7y ago
  > it's especially important if that extra efficiency buys company value. If you've figured out that this is the case, the optimization is no longer premature.
  - hinkley 7y ago
    I can't recall the last time I heard someone say "premature optimization is root of all evil" as a sanity check to someone who was overdoing things. In fact it may have been more than 20 years ago. For one, there are usually better arguments around code comprehension. Pretty much the only time I hear this statement is as a response to criticism. That should raise some questions about the motivations of the speaker. Quite often it comes off as a dodge, and why and what are they dodging? Additionally, the whole quote is often at odds with the point the speaker is trying to make. It's not small inefficiencies, it's factors of 5, or 10, or an extra 6 months before we run out of headroom on something.
- hinkley 7y ago
  > premature optimization is root of all evil Aka the first refuge of the intellectually lazy.
  - 7y ago

HelloNurse 7y ago

A competent and responsible programmer should know how good, on a scale from cheaply done prototype to provably optimal, the 24-hour report is. In the first case, rewriting for better performance is part of the first implementation, not a risky change.