3 ms·

Why do people seem to think that optimization is something you only have to deal with once the software scales so much that 100s of TB of memory or disk space (

Why do people seem to think that optimization is something you only have to deal with once the software scales so much that 100s of TB of memory or disk space (or thousands of hours of processing time) are being wasted. It is almost like nobody even thought during the design phase about what might happen down the road. This is why so much software is bloated and often buggy. Just gets something that half-way works out the door ASAP and worry about the rest later (too often, never).

jacquesm 1mo ago
It can be quite hard to predict where particular usage patterns will take a piece of software under extreme load, especially with things that have lots of internal state. Obviously when you get to spend 100 T or more the pay off of an optimization is much larger than what it is in the case of 1T or less, and your typical developer is not going to have that kind of memory even in aggregate to play with. I tend to be forgiving when it comes to watching software bloat that I did not cause myself (and yet, I'm frustrated that Ubuntu's start-up greeting message takes a whopping 500 M). In the case of internet infrastructure I don't think there was anybody even up to the year 2000 who had any idea of how bit this was going to be. And even now we have IPV4 and lots of legacy to deal with. Cloudflare is not my favorite company, let's put it like that, but in this case they show how the sausage is made and I think that should be applauded. Much better than 'why were down again for X hours'.
philippta 1mo ago
I recently heard a great analogy for this exact problem under the premise of "Make it work, make it right, make it fast". Assume a sorting algorithm as a metaphor for your whole program. You make it work by implementing the simplest thing you know how to write: bubble sort. Works. At the end you notice it's way too slow and replace with something much better: quicksort. Now, how much of your program is surviving? Almost nothing, perhaps except for the "greater than" comparison. If you apply that idea to a real world program, we're pretty much talking about a full rewrite.
- jacquesm 1mo ago
  You could have picked a better example, sorting algorithms are typically drop-in replacements.

jacquesm 1mo ago

It can be quite hard to predict where particular usage patterns will take a piece of software under extreme load, especially with things that have lots of internal state. Obviously when you get to spend 100 T or more the pay off of an optimization is much larger than what it is in the case of 1T or less, and your typical developer is not going to have that kind of memory even in aggregate to play with. I tend to be forgiving when it comes to watching software bloat that I did not cause myself (and yet, I'm frustrated that Ubuntu's start-up greeting message takes a whopping 500 M). In the case of internet infrastructure I don't think there was anybody even up to the year 2000 who had any idea of how bit this was going to be. And even now we have IPV4 and lots of legacy to deal with. Cloudflare is not my favorite company, let's put it like that, but in this case they show how the sausage is made and I think that should be applauded. Much better than 'why were down again for X hours'.

philippta 1mo ago

I recently heard a great analogy for this exact problem under the premise of "Make it work, make it right, make it fast". Assume a sorting algorithm as a metaphor for your whole program. You make it work by implementing the simplest thing you know how to write: bubble sort. Works. At the end you notice it's way too slow and replace with something much better: quicksort. Now, how much of your program is surviving? Almost nothing, perhaps except for the "greater than" comparison. If you apply that idea to a real world program, we're pretty much talking about a full rewrite.

jacquesm 1mo ago
You could have picked a better example, sorting algorithms are typically drop-in replacements.