Author fails to acknowledge that there are many fields where we ship only once and we should strive towards that if we want to avoid running firmware updates on our ultrasonic knives.
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.
I mostly agree with the author that optimizing a code base for change should be the number 1 priority, but I think it is different topic than for example application performance. And it is not an either-or ... you can actually do both, the question - as always - is if you should do it all.
- 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.
> 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.
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.
Author fails to acknowledge that there are many fields where we ship only once and we should strive towards that if we want to avoid running firmware updates on our ultrasonic knives.
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.
> If you have high team fluctuation, optimize for readability.
Or better: If you have high team fluctuation, optimize that first so your team is actually effective.
I mostly agree with the author that optimizing a code base for change should be the number 1 priority, but I think it is different topic than for example application performance. And it is not an either-or ... you can actually do both, the question - as always - is if you should do it all.
- 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.
> 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.
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.
This blog post reads like AI slop.
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.