Hacker News Reader

Comment by rgbrenner | Hacker News Reader

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.

View on HN

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.

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

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.

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.

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.

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.

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

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.

This is the cycle of every "premature optimization" discussion, ever. Someone discounts optimization, but when countered with optimizations states that they aren't actually optimizations.

Your root post states "In fact, most code doesn't need to be optimized at all". That is de facto meaningless if we go under the assumption that optimizing itself -- ergo implementing optimally -- doesn't count as optimizing.

You've thrown a lot of stuff under the label of optimization.

Take coherent design. I started off saying everything should be written for clarity, and having a coherent design is part of that.

A coherent design can mean the code has lower performance than an incoherent design.

How could this possibly be considered an optimization? An optimization now includes things that reduce performance?!

Edit: Also "implementing optimally" is not the definition of optimization. optimal: "best or most favorable." optimize: "rearrange or rewrite (data, software, etc.) to improve efficiency of retrieval or processing."

I think you should revisit the line in the linked page that you disagreed with so strongly. It doesn't say "go back and rewrite in assembly", but simply asks that you develop with performance in mind (with an awareness of the costs of the choices you are making). Your comment was that performance effectively doesn't matter, deal with that later.

Optimization in the context of "premature-optimization" doesn't refer to going back and rewriting code early. It refers to a mental concern about performance, where there is a very wrong, but persistent and common, attitude that performance is something you can add later. But in most cases that simply isn't true, and it's one of the biggest lies in this industry, trotted out like it's grizzled experience and wisdom when it's the foundation of countless project failures.

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.

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

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

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

Reply on news.ycombinator.com