5 ms·

We’re a startup and focussed on easy horizontal scalability early on. From a management point of view premature optimizations are cost intensive, especially whi

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.

loukrazy 6y ago
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.
- Scotrix 6y ago
  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.
- peteradio 6y ago
  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.
  - abraae 6y ago
    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.
- otabdeveloper4 6y ago
  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.)
curyous 6y ago
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.
- Scotrix 6y ago
  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.
  - ZephyrBlu 6y ago
    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.
    - BoorishBears 6y ago
      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.
gameswithgo 6y ago
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.
- ZephyrBlu 6y ago
  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"
  - jtbayly 6y ago
    premature optimizations are by definition premature and that’s what makes it a tautology.
  - ALittleLight 6y ago
    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?
    - kaoD 6y ago
      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.
      - cortesoft 6y ago
mrzimmerman 6y ago
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.
- mobilemidget 6y ago
  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
  - tehjoker 6y ago
    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.
cwingrav 6y ago
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.
im_down_w_otp 6y ago
Aren't you prematurely optimizing for "easy horizontal scalability"?
ineedasername 6y ago
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.

loukrazy 6y ago

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.

Scotrix 6y ago
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.
peteradio 6y ago
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.
- abraae 6y ago
  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.
otabdeveloper4 6y ago
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.)

curyous 6y ago

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.

Scotrix 6y ago
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.
- ZephyrBlu 6y ago
  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.
  - BoorishBears 6y ago
    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.

gameswithgo 6y ago

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.

ZephyrBlu 6y ago
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"
- jtbayly 6y ago
  premature optimizations are by definition premature and that’s what makes it a tautology.
- ALittleLight 6y ago
  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?
  - kaoD 6y ago
    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.
    - cortesoft 6y ago

mrzimmerman 6y ago

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.

mobilemidget 6y ago
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
- tehjoker 6y ago
  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.

cwingrav 6y ago

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.

im_down_w_otp 6y ago

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

ineedasername 6y ago

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.