In negotiations, there's a term called anchoring. It refers to the concept that whatever first number is dropped in a conversation, is the number that will be the mental anchor for the rest of the negotiation. It's why you should avoid saying the first number in any negotiation - if you're too low, you've anchored yourself needlessly on the wrong thing.
Engineering Teams do the same thing, at least I've seen it happen a few times. But that's not anchoring on price levels (probably also, but that's for another post), I'm talking about performance anchoring. When you're joining a team, and someone tells you that retrieving one entity from the Database takes 5 seconds, what's your reaction? It's a bit excessive for 2024, isn't it? Of course, you're diving a bit deeper into the context and the explanations and the history on how it came to be and, well, it's still excessive. But after a while, that edge wears off and it becomes a little more normal, day by day, hour by hour. And instead of driving a realization that some things might not be great, it's rather a journey to normalizing what should not be normalized.
And that's performance anchoring. Normalizing things that behave wildly different from reasonable assumptions. And it's something that drives me mad, because bad performance compounds. It's like a lasagne made up of only bad decisions and spineless management.
It's fair to characterize performance anchoring as just another face of the broken window theory, and it's really not far from the original statement, but there's value in being specific on the topic of performance. Performance is an interesting challenge in most teams - whether it's backend, frontend, mobile or even foundational teams that are not running their own stuff. And performance is highly subjective - is 2 seconds a good load time for a page? It depends. But it's also a truism that Google got to where they are today not only by having great results, but also by delivering a ridiculously fast site, back in the days. Performance in itself is a feature, and if it's overlooked, you won't be able to fix that with some half-assed measures. That's why you have to avoid any form of poor performance creeping into your system - and if it's already creeped in, you need to aggressively remove that.
Happy to write something that I can use to quote myself - and here's that: It's 2024. Most things we're doing can, and should be, fast. If your website is slow, it's not because you're doing some computations that no one has ever done before, no. It's because you dropped the ball on modelling the system correctly, figuring out the right architecture or deploying it to where it should be deployed. All of those things can be fixed, poor performance isn't just a fact of life - it's a result of specific actions. So yeah, go care about performance and make things fast.