6 ms·

> I'll go one step further... all new code should be written for clarity only. Optimized only if necessary. I'm not saying you do, but many people I run across

by sbov 9y ago

> I'll go one step further... all new code should be written for clarity only. Optimized only if necessary. I'm not saying you do, but many people I run across who have this point of view do a poor job at measuring the "if necessary" part. You aren't really prepared to detect it without some form of production performance monitoring, meaning on the chart, a level of around 2.5. I would say they should probably change this section of the spreadsheet to emphasize knowledge of performance.

deleted 9y ago
[deleted]
endorphone 9y ago
To add to that point, in my experience the laissez faire optimize-later attitude is often pursued under the notion that you'll just optimize that hot code path or that single function and everything will be glorious. The best of both worlds. In reality such implementations are often death by thousands of cuts, where endemic poor performance makes it impossible to fix without enormous re-engineering. Where users get delighted when a competitor's product is just a little bit faster. This applies at virtually every level. From your web page being just a little bit faster than a competitor, to the sense of fluidity of an app, to being able to host a profitable service on a reasonable set of hardware (we've watched countless Ruby services fold when a trivial system serving a small number of users needs to be scaled across dozens of machines). Performance is one aspect that seldom goes without payoff.
- hueving 9y ago
  If we're just throwing around anecdotes, I've seen significantly more projects fall behind due premature optimization than failing to scale due to the lack of ability to optimize the app. Most products are wrong out of the gate and will see on the order of 0 users. Iterate quickly until you get the features that users actually want and then in the rare case that is unoptimizable just rewrite from the ground up.
  - endorphone 9y ago
    The term "premature optimization" is a peeve of mind as it's effectively a meaningless, prejudicial term. If we're really farcically talking about 0 versus 1+ user products, however, in actuality the user will do a quick test of your wrapped web app with the glacial web services and the slow responsiveness and they'll dismiss it out of hand. A competitor will come along with a spritely alternative that has a fraction of the features and will eat your lunch. This is the demonstrative history of our industry. Over and over again performance (and this is a relative thing -- a CRM with a 1.5s page render time is fine when everything was slow, but suddenly feels archaic and junky when a competitor is effectively instantaneous) has been the difference between winners and losers. But we still have these cheap conversations as if it's a feature that you just bake in later.
- deleted 9y ago
  [deleted]
- rgbrenner 9y ago
  It's not that simple. Optimization is almost always additional complexity. So an argument in favor of optimizing whenever and wherever possible, is an argument in favor of introducing unnecessary complexity. Optimization isn't free. It has a cost to implement (slowing development) and another cost whenever the code is read/refactored/extended/etc (also slowing development time). That second part is incurred by every developer working on that piece of code now and in the future. So the danger in unnecessary optimization is both wasted time and slowing of development, delaying product market fit or making it difficult to respond to competitors introduction of new features (for example). What is the more common story: start up died because competitor was slightly faster; or start up died because they never found product market fit.
  - endorphone 9y ago
    I don't disagree with what you wrote, or the spirit of its meanings. But optimizations in a modern sense seldom means implementing a section in assembly. In most cases it means a skillful, well-considered use of appropriate technologies, appropriate algorithms (e.g. a hash table instead of a simple linked list for a lookup heavy section, appropriate database designs, etc) and a coherent design. When you start from day 1 thinking "performance matters", it doesn't and shouldn't demand any added complexity. But it does demand constant consideration as implementing requirement. Of course the counterpoint is that of course we should use appropriate technologies, algos, designs, etc. Who could argue otherwise? But whenever I've seen the premature optimization boogeyman appear in a modern context, it is usually in the context of just such a discussion. A sort of "performance is a concern for another day".
    - deleted 9y ago
      [deleted]
    - rgbrenner 9y ago
      I don't consider appropriate use of algos (where no additional development cost is incurred), and coherent design to be optimizations. I'm not sure how to respond to this. You're using a definition I've never heard before.. this sounds like basic competency being called optimization. Nothing I've written here should be misconstrued as an argument in favor of sloppy code.
rhizome 9y ago
You aren't really prepared to detect it without some form of production performance monitoring Which is secondary to actually releasing the code. That is, all code is subject to this measurement, and can be used as a signal for refactoring. Ere twas.

by sbov 9y ago

deleted 9y ago

[deleted]

endorphone 9y ago

To add to that point, in my experience the laissez faire optimize-later attitude is often pursued under the notion that you'll just optimize that hot code path or that single function and everything will be glorious. The best of both worlds. In reality such implementations are often death by thousands of cuts, where endemic poor performance makes it impossible to fix without enormous re-engineering. Where users get delighted when a competitor's product is just a little bit faster. This applies at virtually every level. From your web page being just a little bit faster than a competitor, to the sense of fluidity of an app, to being able to host a profitable service on a reasonable set of hardware (we've watched countless Ruby services fold when a trivial system serving a small number of users needs to be scaled across dozens of machines). Performance is one aspect that seldom goes without payoff.

hueving 9y ago
If we're just throwing around anecdotes, I've seen significantly more projects fall behind due premature optimization than failing to scale due to the lack of ability to optimize the app. Most products are wrong out of the gate and will see on the order of 0 users. Iterate quickly until you get the features that users actually want and then in the rare case that is unoptimizable just rewrite from the ground up.
- endorphone 9y ago
  The term "premature optimization" is a peeve of mind as it's effectively a meaningless, prejudicial term. If we're really farcically talking about 0 versus 1+ user products, however, in actuality the user will do a quick test of your wrapped web app with the glacial web services and the slow responsiveness and they'll dismiss it out of hand. A competitor will come along with a spritely alternative that has a fraction of the features and will eat your lunch. This is the demonstrative history of our industry. Over and over again performance (and this is a relative thing -- a CRM with a 1.5s page render time is fine when everything was slow, but suddenly feels archaic and junky when a competitor is effectively instantaneous) has been the difference between winners and losers. But we still have these cheap conversations as if it's a feature that you just bake in later.
deleted 9y ago
[deleted]
rgbrenner 9y ago
It's not that simple. Optimization is almost always additional complexity. So an argument in favor of optimizing whenever and wherever possible, is an argument in favor of introducing unnecessary complexity. Optimization isn't free. It has a cost to implement (slowing development) and another cost whenever the code is read/refactored/extended/etc (also slowing development time). That second part is incurred by every developer working on that piece of code now and in the future. So the danger in unnecessary optimization is both wasted time and slowing of development, delaying product market fit or making it difficult to respond to competitors introduction of new features (for example). What is the more common story: start up died because competitor was slightly faster; or start up died because they never found product market fit.
- endorphone 9y ago
  I don't disagree with what you wrote, or the spirit of its meanings. But optimizations in a modern sense seldom means implementing a section in assembly. In most cases it means a skillful, well-considered use of appropriate technologies, appropriate algorithms (e.g. a hash table instead of a simple linked list for a lookup heavy section, appropriate database designs, etc) and a coherent design. When you start from day 1 thinking "performance matters", it doesn't and shouldn't demand any added complexity. But it does demand constant consideration as implementing requirement. Of course the counterpoint is that of course we should use appropriate technologies, algos, designs, etc. Who could argue otherwise? But whenever I've seen the premature optimization boogeyman appear in a modern context, it is usually in the context of just such a discussion. A sort of "performance is a concern for another day".
  - deleted 9y ago
    [deleted]
  - rgbrenner 9y ago
    I don't consider appropriate use of algos (where no additional development cost is incurred), and coherent design to be optimizations. I'm not sure how to respond to this. You're using a definition I've never heard before.. this sounds like basic competency being called optimization. Nothing I've written here should be misconstrued as an argument in favor of sloppy code.

rhizome 9y ago

You aren't really prepared to detect it without some form of production performance monitoring Which is secondary to actually releasing the code. That is, all code is subject to this measurement, and can be used as a signal for refactoring. Ere twas.