5 ms·

Some of this is just completely wrong. Like the entire row titled code performance. Level 4 isn't going around your codebase shaving milliseconds from executio

Some of this is just completely wrong. Like the entire row titled code performance. Level 4 isn't going around your codebase shaving milliseconds from execution time.. Level 4 is knowing that not everything needs to be optimized.. In fact, most code doesn't need to be optimized at all. The only parts that actually need optimization are those that have been deemed to be too slow (because of some external reason--ie: effect on users, for ex) or that are on a hot code path. I'll go one step further... all new code should be written for clarity only. Optimized only if necessary. No one cares if your function thats called once a month takes an extra few seconds to run.

rishabhparikh 9y ago
This is a great point. I'm just now realizing all the times I wasted time optimizing things for MVPs because of coder OCD
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.
- 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.
lallysingh 9y ago
This is one of those cases where people are extrapolating left->right to fill a table row.
xivusr 9y ago
Absolutely agree that clarity is far more important in the early stages than pre-optimization.
tetha 9y ago
Also no one cares about your loop optimization if you're wasting 20 seconds in the network because you aren't using your ORM right. Also no one cares about your memory efficiency if you're sending megabytes of json to the client. Include network time in that as well. Also no one cares about your optimization if the GC goes postal. I maintain 2 positions, though we can discuss about the details: - There is unoptimized code, and there's just stupid code. I'm fine with raw code without optimizations. But I hate code making all mistakes from the last 2 years of the company, and the last 10 years of experience in this industry again and again and again. - All other optimization should be done based on production monitoring. Or, production-like loadtests if you have that luxury. For a new feature, good monitoring will allow a good developer to increase performance significantly with very small changes. For a legacy clusterfuck, good monitoring will allow devs and ops to build a strong case for a bigger rework. Which will result in much larger benefits for both teams.

rishabhparikh 9y ago

This is a great point. I'm just now realizing all the times I wasted time optimizing things for MVPs because of coder OCD

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

lallysingh 9y ago

This is one of those cases where people are extrapolating left->right to fill a table row.

xivusr 9y ago

Absolutely agree that clarity is far more important in the early stages than pre-optimization.

tetha 9y ago

Also no one cares about your loop optimization if you're wasting 20 seconds in the network because you aren't using your ORM right. Also no one cares about your memory efficiency if you're sending megabytes of json to the client. Include network time in that as well. Also no one cares about your optimization if the GC goes postal. I maintain 2 positions, though we can discuss about the details: - There is unoptimized code, and there's just stupid code. I'm fine with raw code without optimizations. But I hate code making all mistakes from the last 2 years of the company, and the last 10 years of experience in this industry again and again and again. - All other optimization should be done based on production monitoring. Or, production-like loadtests if you have that luxury. For a new feature, good monitoring will allow a good developer to increase performance significantly with very small changes. For a legacy clusterfuck, good monitoring will allow devs and ops to build a strong case for a bigger rework. Which will result in much larger benefits for both teams.