3 ms·

So the biggest tech companies in the world, now that they are huge, are making their programs faster. OK. To me, that says maybe the reason they beat their comp

by ftxbro 4y ago

So the biggest tech companies in the world, now that they are huge, are making their programs faster. OK. To me, that says maybe the reason they beat their competition to becoming huge, was that they wrote a lot of features quickly and didn't nitpick about performance. Maybe the ones that wrote efficient high performance code from the start stayed small or were out-competed.

simula67 4y ago
When I was starting out using the web, one of the reasons for using Google over competition was that it was fast. The home page loaded fairly quickly, and the results were instantaneous. Google spent a lot of time optimizing for performance during its early years and they were explicit about it.
- yonixw 4y ago
  The problem with this argument is that there are many contradicting sample points. Like chrome. On one hand, Google created the JS-Engine V8 which finally made the web fast. But on the other hand, did nothing to fix the RAM issues that came with that until recent years. So I see it as "Let's do performance only when it's an advantage for us". Which all of the OP examples falls to. OP want to conclude from that that performance=advantage so everyone need to work on it all the time (because who will ignore advantages?), but all we see is if(performance=advantage){refactor}. Which does not support his conclusion. Example cases are startups, monopoles, high cost (like refactoring bank code) etc. which have other silos of advantage.
AbsoluteCabbage 4y ago
you realize that you are literally parroting talking points that we have already predicted you would come up with as additional excuses, right?
- ftxbro 4y ago
  I mean I'm not parroting anything, but OK I will also agree that this isn't an especially mind blowing point that I was making. Probably a lot of other people would make that same point too!
- yonixw 4y ago
  He didn't refute "start faster, refactor later" at all, with any of his examples. So him saying he did, does not matter. "Evidence" as he says, is needed.
  - matiasfernandez 4y ago
    “For example, one argument would be that the evidence I’ve presented here is consistent with a strategy of quickly shipping “version one” with poor performance, then starting work on a high-performance “version two” to replace it. That would be completely consistent with the evidence we see. But even if that turns out to be true, it still means programmers have to care about performance! It just means they need to learn two modes of programming: “throw-away”, and “performant”. There would still be no excuse for dismissing performance as a critical skill, because you always know the throw-away version has to be replaced with a more performant version in short order. That kind of argument is great. We should have it. What we should not have are excuses — claims there is no argument to be had, and that performance somehow won’t matter anywhere in a product lifecycle, so developers simply don’t have to learn about it.”

by ftxbro 4y ago

simula67 4y ago

When I was starting out using the web, one of the reasons for using Google over competition was that it was fast. The home page loaded fairly quickly, and the results were instantaneous. Google spent a lot of time optimizing for performance during its early years and they were explicit about it.

yonixw 4y ago
The problem with this argument is that there are many contradicting sample points. Like chrome. On one hand, Google created the JS-Engine V8 which finally made the web fast. But on the other hand, did nothing to fix the RAM issues that came with that until recent years. So I see it as "Let's do performance only when it's an advantage for us". Which all of the OP examples falls to. OP want to conclude from that that performance=advantage so everyone need to work on it all the time (because who will ignore advantages?), but all we see is if(performance=advantage){refactor}. Which does not support his conclusion. Example cases are startups, monopoles, high cost (like refactoring bank code) etc. which have other silos of advantage.

AbsoluteCabbage 4y ago

you realize that you are literally parroting talking points that we have already predicted you would come up with as additional excuses, right?

ftxbro 4y ago
I mean I'm not parroting anything, but OK I will also agree that this isn't an especially mind blowing point that I was making. Probably a lot of other people would make that same point too!
yonixw 4y ago
He didn't refute "start faster, refactor later" at all, with any of his examples. So him saying he did, does not matter. "Evidence" as he says, is needed.
- matiasfernandez 4y ago
  “For example, one argument would be that the evidence I’ve presented here is consistent with a strategy of quickly shipping “version one” with poor performance, then starting work on a high-performance “version two” to replace it. That would be completely consistent with the evidence we see. But even if that turns out to be true, it still means programmers have to care about performance! It just means they need to learn two modes of programming: “throw-away”, and “performant”. There would still be no excuse for dismissing performance as a critical skill, because you always know the throw-away version has to be replaced with a more performant version in short order. That kind of argument is great. We should have it. What we should not have are excuses — claims there is no argument to be had, and that performance somehow won’t matter anywhere in a product lifecycle, so developers simply don’t have to learn about it.”