Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Optimize for change not application performance

echooff.dev

Post reply on HN
Print view View original

31–39 of 39 posts

Re: Optimize for change not application performance

#31

Post by lo1tuma »

moebrowne wrote: post #23

I agree with the overall sentiment of this post but I'm not sure about this: > 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.

I assume that the author means, when it is easy to change something in the code (i.e. without fear because you have a very good test automation), then it is easy to apply changes like performance optimizations.

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.

Re: Optimize for change not application performance

#32

Post by lo1tuma »

kikimora wrote: post #9

If done right optimizing for performance also achieves readability and maintenance. There is an edge case when you rewrite a loop with SIMD or use branch less programming. It is so rare but a focus of so many articles. 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…

I agree. Over-engineering is something many projects suffer from. Principles like YAGNI and KISS help, but it is hard to enforce them by tooling. So it remains a discipline of the engineers.

Re: Optimize for change not application performance

#33

Post by lo1tuma »

nijave wrote: post #11
kikimora wrote: post #9

If done right optimizing for performance also achieves readability and maintenance. There is an edge case when you rewrite a loop with SIMD or use branch less programming. It is so rare but a focus of so many articles. 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…

Nothing like waiting 20 minutes for a test suite that should have taken 2

Yep, fast feedback cycles are important.

Re: Optimize for change not application performance

#34

Post by lo1tuma »

po1nt wrote: post #3

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.…

Very true. I think the authors area settles more in the webdev area, where you can make releases multiple times per day.

> 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.

Re: Optimize for change not application performance

#35

Post by 0123456789ABCDE »

po1nt wrote: post #25
0123456789ABCDE wrote: post #16

Earlier quoted context omitted.

but do we care, if management doesn't?

I do take pride in my work. Keeps me from going insane and switching careers to take on leatherworking. Even if I have to fight the uphill battle with incompetency.

not to dunk on you, but you're following "Keeps me from going insane" with "Even if I have to fight the uphill battle with incompetency"

Re: Optimize for change not application performance

#36

Post by bunderbunder »

po1nt wrote: post #22
bunderbunder wrote: post #18

Earlier quoted context omitted.

I do wonder if sometimes these things are set up as false dilemmas, though. 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…

Removing null pointer guards would improve readability, not safety. Removing hashing on passwords would also improve readability and made the program easier to debug.

That feels like a strawman to me? Both of those are examples of simply not implementing functional requirements, which is never ok.

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.

Re: Optimize for change not application performance

#37

Post by po1nt »

bunderbunder wrote: post #36
po1nt wrote: post #22

Earlier quoted context omitted.

Removing null pointer guards would improve readability, not safety. Removing hashing on passwords would also improve readability and made the program easier to debug.

That feels like a strawman to me? Both of those are examples of simply not implementing functional requirements, which is never ok. 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 celeb…

Safety is almost never functional requirement (unless for OpenSSL and such projects). You can always focus just on the happy path expecting users will behave. Even in Rust you can unwrap on unexpected value instead of handling it properly. It will lower the LoC, thus increasing readability but possibly crashing the program on unexpected inputs. Possibly leaving open doors for DoS where attacker would just spam invalid input and crashing the server.

Re: Optimize for change not application performance

#38

Post by nijave »

lo1tuma wrote: post #32
kikimora wrote: post #9

If done right optimizing for performance also achieves readability and maintenance. There is an edge case when you rewrite a loop with SIMD or use branch less programming. It is so rare but a focus of so many articles. 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…

I agree. Over-engineering is something many projects suffer from. Principles like YAGNI and KISS help, but it is hard to enforce them by tooling. So it remains a discipline of the engineers.

In 2026, I remain hopeful AGENTS.md can help close that gap

Re: Optimize for change not application performance

#39

Post by kikimora »

nijave wrote: post #38
lo1tuma wrote: post #32

Earlier quoted context omitted.

I agree. Over-engineering is something many projects suffer from. Principles like YAGNI and KISS help, but it is hard to enforce them by tooling. So it remains a discipline of the engineers.

In 2026, I remain hopeful AGENTS.md can help close that gap

Reading a DDD book does not make you a good architect. Often it makes you worse :) How AI or agents supposed to learn this art?
Post reply on HN