4 ms·

Ya I have worked with the optimize at the end guys before. Really, you are gonna refactor a 100k Java codebase to be fast when its done? Want to know how much e

Ya I have worked with the optimize at the end guys before. Really, you are gonna refactor a 100k Java codebase to be fast when its done? Want to know how much easier it is to plan for speed from day 1?

IanCal 10y ago
As always, going too far either way is a bad idea. I've worked with "optimise everything ahead of time" people before and it can be an astonishing waste of time. You shouldn't completely ignore performance all the way through and assume you can sprinkle it on top later, but you shouldn't spend months squeezing the last few ms out of a feature that the client will change / remove when they try it anyway. > Really, you are gonna refactor a 100k Java codebase to be fast when its done? Maybe? Depends where the problems are. If the problems are huge architectural ones, no that sounds terrible. If the problem can be solved by later improving an inner loop somewhere and getting things solved then sure.
- mozumder 10y ago
  Speed is user-experience. People used Instagram at first because it was fast. And they were quickly bought out for a billion.
  - catshirt 10y ago
    I never heard someone say "I use instagram because it's fast"
    - brianwawok 10y ago
      But how many people don't X because it's slow? I don't browse on my phone's because ads make it too slow.
  - deleted 10y ago
    [deleted]
  - IanCal 10y ago
    Speed is part of the user experience, but again it's more complex than that. Nobody would have used snapchat if it didn't take photos but the site loaded in 1ms. Nobody would use it if it had loads more features and took 2 hours. Speed is a part of it, and must be traded off with all the other parts of the user experience.
  - deleted 10y ago
    [deleted]
jonaf 10y ago
Your particular example made me smile. I'm currently leading a team whose primary product is the front end service for the core SaaS business that does billions of monthly impressions (hundreds of millions of uniques). This product is over 10 years old, written in Spring, and has around 400,000 lines of Java. A couple years ago, we underwent a massive overhaul to the system and refactored the application to use our realtime steaming platform instead of using MySQL+Solr. It took some time to get it done, mainly because at the time there were about 8 years of features baked into a monolithic web service. Ultimately, we were successful in the endeavor. It took about 2.5 years and our response times are dramatically faster (and less expensive in terms of infrastructure cost). So yeah, you can do it. It's expensive and takes time if you wait too long. And you need full support from the business. And some companies don't survive it. YMMV.
lojack 10y ago
It's helpful to separate performance from the ability to perform. It's generally not the greatest idea to prematurely optimize, but you should absolutely be making decisions that give you the flexibility to optimize in the future. For instance, adding a caching layer before it's needed may be a bad idea, but organizing your data in such a way that you could easily add a caching layer may be a good idea. Making your website in C because it's fast may be a bad idea, but choosing Python because you could easily add C bindings to the slow parts may be a good idea.
atmartins 10y ago
Yeah but if it takes 6 months longer, and is 30% harder to refactor, it doesn't matter. You're not selling anything when it's not running.

IanCal 10y ago

As always, going too far either way is a bad idea. I've worked with "optimise everything ahead of time" people before and it can be an astonishing waste of time. You shouldn't completely ignore performance all the way through and assume you can sprinkle it on top later, but you shouldn't spend months squeezing the last few ms out of a feature that the client will change / remove when they try it anyway. > Really, you are gonna refactor a 100k Java codebase to be fast when its done? Maybe? Depends where the problems are. If the problems are huge architectural ones, no that sounds terrible. If the problem can be solved by later improving an inner loop somewhere and getting things solved then sure.

mozumder 10y ago
Speed is user-experience. People used Instagram at first because it was fast. And they were quickly bought out for a billion.
- catshirt 10y ago
  I never heard someone say "I use instagram because it's fast"
  - brianwawok 10y ago
    But how many people don't X because it's slow? I don't browse on my phone's because ads make it too slow.
- deleted 10y ago
  [deleted]
- IanCal 10y ago
  Speed is part of the user experience, but again it's more complex than that. Nobody would have used snapchat if it didn't take photos but the site loaded in 1ms. Nobody would use it if it had loads more features and took 2 hours. Speed is a part of it, and must be traded off with all the other parts of the user experience.
- deleted 10y ago
  [deleted]

jonaf 10y ago

Your particular example made me smile. I'm currently leading a team whose primary product is the front end service for the core SaaS business that does billions of monthly impressions (hundreds of millions of uniques). This product is over 10 years old, written in Spring, and has around 400,000 lines of Java. A couple years ago, we underwent a massive overhaul to the system and refactored the application to use our realtime steaming platform instead of using MySQL+Solr. It took some time to get it done, mainly because at the time there were about 8 years of features baked into a monolithic web service. Ultimately, we were successful in the endeavor. It took about 2.5 years and our response times are dramatically faster (and less expensive in terms of infrastructure cost). So yeah, you can do it. It's expensive and takes time if you wait too long. And you need full support from the business. And some companies don't survive it. YMMV.

lojack 10y ago

It's helpful to separate performance from the ability to perform. It's generally not the greatest idea to prematurely optimize, but you should absolutely be making decisions that give you the flexibility to optimize in the future. For instance, adding a caching layer before it's needed may be a bad idea, but organizing your data in such a way that you could easily add a caching layer may be a good idea. Making your website in C because it's fast may be a bad idea, but choosing Python because you could easily add C bindings to the slow parts may be a good idea.

atmartins 10y ago

Yeah but if it takes 6 months longer, and is 30% harder to refactor, it doesn't matter. You're not selling anything when it's not running.