Hacker News Reader

Comment by Scotrix | Hacker News Reader

We’re a startup and focussed on easy horizontal scalability early on. From a management point of view premature optimizations are cost intensive, especially while we’re still figuring out what our product is and how it works. At the end there are a lot of changes all the time to functionality and implementation and optimizations early get wasted very quickly. We rather purchase new servers. A powerful server cost 100 USD/month and wehe development team can focus on implementing features and functionality which moves our product forwar d, optimizations are opportunity losses at the beginning of a product. Of course, as soon as bad performance impacts user experience it’s a different story and also if you start to have hundreds or thousands of servers but then you’ll know what your product is doing and changes become smaller, focused and code optimizations start to make sense.

View on HN

That's not an argument not to optimize, that's an argument to consider the costs & implications of optimization. Failing to do that now can cost much more later on when compute resources need balloon and product scope/codebase is much larger, making optimizations more labor intensive.

There's no yes/no on this. It's all on a slider, a spectrum.

premature optimizations being bad is a tautology.

optimizations that are not premature are a win though, and by making it standard to consider performance issues from the outset, you and tour team get better at it, such that it doesn’t cost time to default to pretty efficient solutions.

also some basic tech choices can often get you large constant factor wins without any downsides, like using a languages that are at least jitted rather than interpreted.

It's not a tautology, the parent comment clearly outlined some very good reasons for not prematurely optimizing things.

- "At the end there are a lot of changes all the time to functionality and implementation and optimizations early get wasted very quickly"

- "optimizations are opportunity losses at the beginning of a product"

premature optimizations are by definition premature and that’s what makes it a tautology.

It is a tautology because the word "premature" means "before you have to" in this context. It's like saying "You don't need to do things before you need to need to do them." It's true by definition.

The question is: which optimizations are premature and which aren't?

I'd say it's not only a tautology, it's plain false.

Cheap optimizations that are known to work (compiling in release mode, enabling HTTP cache in your web server, using a fast sorting algorithm on large arrays...) are good even if you don't need them right now.

That would mean they aren't premature

But the question still valid, which are and which aren't (premature)? For experts: avoiding n+1 query, using hash map rather than loop match, caching in memory, using smaller data type, all are standard optimization techinques.

Now if junior doesn't implement them, are they didn't do required optimization, or do they do premature optimization if they did?

"premature" is in the eye of the beholder... (or implementer). I've cleaned up a lot of slow code over the last few years, and in most cases the 'fixes' are pretty simple. The pushback was typically along the lines of "YAGNI" and "premature optimization is the root of all evil" quotes, yet... yeah, you know what, we ARE "gonna need it", and adding a table index on a column you're querying on in a where clause isn't "premature". It's industry standard practice.

You don’t NEED them. They are premature. I don’t technically need to compile my app in release-mode as a small startup.

> I'd say it's not only a tautology, it's plain false.

And that, my friends, is a contradiction!

I think what the others are trying to say is that 'premature' is generally a label applied in hindsight.

The preparations you made that turned out to make your life easier, the things you regret not doing, and the things that ended up being a total waste of time.

What about the cost of putting shitty, slow software into the world?

How about having respect for you user's time? Depending on how many users you have, shaving seconds or milliseconds off your response time will save humanity hundreds, thousands, or millions of hours waiting for your software to do something.

It depends on the product and the user/customer impact, if it doesn’t matter that it takes 200ms or 300ms why do you care? Also, if it matters and you can scale horizontally to improve performance do that first instead of spending valuable developers hours.

I think it's difference in the hacker/product mindset and the engineer mindset.

For hackers or product focused devs, making something work is the most important aspect whereas for engineering focused devs, it hurts to see such large inefficiencies that are solvable.

I empathize with the engineer mindset, but definitely align more with the hacker/product mindset.

I feel the latter is just not being able to see the big picture.

People in the latter mindset don't get that providing real value to users is what matters.

Literally everything boils down to it. Even the example of making a faster application, it's literally only useful in that it increases how quickly you generate user value.

At some point once you generate enough value for your end user, the utility will outweigh a given latency problem.

Even making your server costs cheaper with optimization really matters because you can transform the savings into user value that exceeds the cost of optimizing.

So it really doesn't make sense to thumb your nose down at people who are "just sticking stuff they don't understand together" in a vaccum like they tend to do.

You don't know their runway.

You don't know how concrete their business case is.

You don't know their development budget.

The moment you're making a dichotomy between yourself and "those programmers who just put shiny legos they don't understand together", you're demonstrating a lack of understanding of the bigger picture that development fits in.

Because sometimes hiring someone who has little experience outside clicking those legos together is all that allows an idea to exist.

tl;dr: A service that loads with 100 requests instead of 1 because the developer doesn't know better still generates more value to the end user than one that doesn't exist.

The even bigger picture is that we (as people, who all use various services in our daily life) end up with all these services being slow and frustrating, although they do provide value, resulting in an overall frustrating daily experience.

Nothing about what I said is anti-making a service faster, reducing frustration is certainly valuable to a user.

But the simple fact is some of those services simply would not exist in another form.

Another way to look at it is if they could exist in a meaningfully faster form easily, competitors would pick up on that.

The non-existence of a bad service allows a better service to come into existence. All too often a market is dominated by some company that got lucky and now has no incentive to improve.

After your first sentence I thought you'd continue like this:

For a hacker, making something fast and cool is the most important aspect, whereas for engineers making careful tradeoffs between effort and customer impact are the main focus.

I think you could swap 'hacker' and 'engineer' in your sentence and it would still make sense.

I'm not saying, "engineer bad, hacker good", just that we tend to value "good" code, architecture, performance, etc highly and sometimes that is to our detriment.

Operative word “careful”

I happen to have it on good authority that there is an endpoint lurking somewhere in our API that has a p99 latency of almost 3 full hours per request. We clearly don't respect our users time. Or our own. Or basic software engineering practices. Sigh.

That is amazing. It must be quite the tenacious client that doesn't timeout on that.

Yeah client's will timeout for sure after a few minutes. The API doesn't know that though... it'll just sit there wasting an ungodly amount of resource and causing tonnes of noisy neighbor problems. You look in the APM traces and see one with 8 million spans that enumerates the whole database. Just silly. It's easy to be a 10x engineer in an environment where there is a lot of 0.1x engineering :(

Aren't you prematurely optimizing for "easy horizontal scalability"?

Yeah, I think the article makes a good point on the impact that optimization can make but I use the same strategy that you do at my current job. Early on it just makes a lot more sense to focus on what can generate revenue.

Make it work Make it work good Make it work fast

I think I read this here years ago as order of development, maybe quote from somebody else even, I forgot

Depending on your field, making things work fast may be the difference between it not working, working at all, and willing to be adopted by other practitioners.

Completely right. You are correct in what you should be focusing on. Only very large systems will see a return on investment in optimizing a system for hardware costs (bad code and crummy implementations should be worked out as tech debt). Focus on product, features and serving your customers. Get your market fit and burn your investor capital. Then when you reach that next stage, either sell to a company that is good at management or start hiring for performance.

Not to mention the cost of X more servers for a year is probably less costly than the developer time of optimization and the opportunity cost.

Indeed, that’s basically the point as well. I have seen developers hunting for the „right“ way and best performance even to the microsecond level for no good business reason while ignoring the state of a project/product and the required value they should focus on.

On the other end of the spectrum, really poorly performing code can affect development, testing and delivery times which eats developer time as well. Some developers or testers might sit oh welling waiting for 1hr job to finish when 1 day of development time could turn that job into a 5min run. That kind of optimization pays for itself before it even makes it to production.

Adding poorly performing code is a bit like pissing in a swimming pool.

A little bit is ok. If you have to. But too much of it and there's no way back other than draining the pool and starting again.

It's not necessarily either/or. In my experience, the really crappy developers who can't write optimized code are also the ones who are really slow and expensive in developing even the most basic features.

(And the converse is also usually true.)

Reply on news.ycombinator.com