Optimize for change not application performance
echooff.dev
echooff.dev
While we talk about maintainability, we all admire Fast Inverse Square algorithm.
Optimize for what best serves your purpose. If you have high team fluctuation, optimize for readability. If you develop a spacecraft, optimize for safety. If you ship audio gear, optimize for latency.
Or better: If you have high team fluctuation, optimize that first so your team is actually effective.
I skimmed through NASA’s coding manual a while back, and one of the things that I took away from it was that optimizing for readability is optimizing for safety.
It’s just that it’s hard for me to see it as readability because I’m not familiar with the problem domain. For example, their ban on reentrancy would definitely require me to rewire my brain a bit. But, for what they are doing, that is a readability decision: they needed to be able to guarantee that a spacecraft’s firmware couldn’t experience a stack overflow, and reentrant code makes it much harder to reason about stack growth.
For storing passwords in the clear, that should be obvious.
For null checks it may be more subtle, but consider the case of languages like Rust and Kotlin that let you eliminate null checks and replace them with static guarantees that a reference won’t be null. In noth cases that’s celebrated as a win for both safety and readability. So I’m inferring an unstated major premise that we’re talking about skipping null checks in functions where null cannot be formally eliminated from the function’s input domain. (Maybe we’re working in Java instead.) In which case I must insist that null checks are good for readability because they explicitly communicate important information about what arguments the function is willing to accept. It’s leaving that important information unstated and implicit that would be bad for readability.
i don't. that guy basically made the same game over and over again, while nearly everyone else was innovating in game design, reaching new audiences, etc. that's what change is about!
and then, he blows up the next thing he's put in charge of (VR), and blames everyone but himself. how many billions did he get and he couldn't figure it out? every bit of ethos from that guy was bad, it's not just the one little ethos of the hardcore little optimization algorithm, it's every ethos.
I personally think he was enormously successful in VR, just not in a market sense but in a technology and UX sense. In my opinion VR is still yet to come to a mass adoption, just not in the "second life" fantasy, but in the "replacement for workspace monitors" kind of way.
> Optimize for what best serves your purpose. If you have high team fluctuation, optimize for readability. If you develop a spacecraft, optimize for safety. If you ship audio gear, optimize for latency.
I fully agree with that.
Wow, TIL.
I do see a lot of system that are both slow and hard to maintain because people focus on maintenance. They create abstractions upon abstractions in the name of maintainability to later find it does not work well with their hardware and infrastructure prompting more complexity in the name of performance.
That isn’t to say abstractions are inherently harmful. But when I see codebases that really go nuts for it, it’s rarely the case that they were all carefully considered before implementation.
> A codebase that is easy to maintain becomes easier to optimize.
I think optimization and maintainability are often at odds. The only example which comes to mind is loop unrolling, increases performance, decreases maintainability.
Things like loop unrolling is probably something I wouldnt do by hand on the source code, I would probably write a script that transforms the code automatically, so the original source code stays readable.
I doubt that the author even read the result, as it's readability is subpar. In general AI slop is more readable than this soup of bullet points.
This feels like eternal September, but powered by LLMs.
- Optimizing for change is basically the key principle of agility. Too ofter it is confused by many people with being fast in delivery by default, just because you apply agile patterns. This is not true. You can be faster than e.g. with waterfall, but most of the time you will be slower. But that is not the point. The point is you can adapt the plan very quickly. So instead of following strictly a 6 months plan, you can change plans on a daily basis and go in completely different direction, if business demands that.
- Application performance is actually not a "tech" thing. So I dont understand why so many developers pre-optimize for application performance without being asked to do so. Application performance is part of UX (User experience). There are studies out there, that sometimes it is even benefitial to be slow and show a loading indicator because it could increase trust from users, because they think "Hey look... the application is calculating something to fullfil my needs", instead of showing the answer instantly. In any case, Application perfomance should be driven by business and user needs, not by engineers who have a personal obligation to do this. And furthermore application performance should never be optimized blindly. Always benchmark the application and work on the bottleneck only.
Users being susceptible to dark patterns doesn't mean that dark patterns are something an engineer should see as acceptable.
> Always benchmark the application and work on the bottleneck only.
That's how you end up with software that's slow due to a million abstractions. Easily bench-marked bottlenecks can give you quick wins, but that doesn't mean you should stop there or not have any foresight to optimize things ahead of time where it makes sense. Your cost benefit calculation also needs to take into account that optimizations decisions (both architecture and lower implementation details) are much more costly to do after the code has already been written, which is why with today's YOLO software they often don't get done at all.
I think it is not even an engineers job to define the UX/UI. I would rather consult an expert on that matter. But from my personal experience I can relate to that. When I see applications that seem to be too performant I often get the feeling that they might be phishing pages because they don’t do any actual work under the hood. So my first instinct is to avoid those kind of pages, even though it might be legit.
> That's how you end up with software that's slow due to a million abstractions.
How is an abstraction related to benchmarking? Those are too completely distinct topics.
> Easily bench-marked bottlenecks can give you quick wins
They can... but most of the time it is not a quick win. But the question is not about if it is quick win or not. The only thing that matters is if your are optimizing on the bottleneck or on something that has no measurable impact. Without benchmarking you are blind.
> but that doesn't mean you should stop there or not have any foresight to optimize things ahead of time where it makes sense
Yes, it does. When the bottleneck is gone, and the performance becomes good enough there is no further need to optimize. I am happily quoting Donald Knuth here "Premature optimization is the root of all evil."
> Your cost benefit calculation also needs to take into account that optimizations decisions
This is true. But it doesn’t only apply to optimizations. This applies to any kind of change you want to make to the code. So this has also been to considered when you want to build a new feature. The answer to that is: Optimize for change. Which is basically the fundamental idea working in an agile way, but most people don’t do this correctly. Optimize for change means you need a lot of test automation and clean code, so you can make any kind of code or architecture change quickly with low cost and low risk and without fear. I am practicing this since over a decade now and it works pretty good.
And I as a user absolutely hate programs that do this. Put an "updated" message with a timestamp if you want, but don't pointlessly waste my time.