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?

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.

Speed is user-experience.

People used Instagram at first because it was fast.

And they were quickly bought out for a billion.

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.

I never heard someone say "I use instagram because it's fast"

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.

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.

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.

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.

But sometimes that fix can only be done by switching to another tech stack or framework.

That is, a complete rewrite.

When that's not possible, we have to endure the constantly crashing and slow as molasses web sites like the ones used in universities by students to enroll in courses.

This is just moving the goalposts. No one is saying you have to do these optimisations upfront, just that you they are worth doing.