3 ms·

People always seem to think "premature optimization" means "premature optimization for speed". But there are lots of otherwise-good things that you can prematur

by _dain_ 3y ago

People always seem to think "premature optimization" means "premature optimization for speed". But there are lots of otherwise-good things that you can prematurely optimize for: - modularity - readability - abstraction - maintainability - scalability - reusability - testability - cost We've all seen codebases that are over-abstracted in the name of code reuse, or to adhere to this or that software design philosophy, and are nightmares as a result. "You Ain't Gonna Need It" is a restatement of the premature-optimization adage, just for a different metric.

whstl 3y ago
And the "premature optimization" excuse is used almost every time someone argues that over-abstraction can cause performance issues.
- hinkley 3y ago
  Or other forms of laziness.
munch117 3y ago
"Premature optimisation" refers to speed or size. Using the phrase to talk about those other things is a stretch. (Except maybe cost.) You can design for modularity, readability etc., but optimising for them doesn't sound right. Something to do with them not having well-defined, agreed-upon definitions of where the optimum is.
- hinkley 3y ago
  I work with a Principle of Maximum Power guy. He’s insufferable. Too smart to browbeat into behaving, and too old to chalk it up to youthful exuberance or lack of experience. He’s made big chunks of the project comfortable for him and miserable for everyone else, so of course he’ll never leave, and people who know they deserve better do.
- chriswarbo 3y ago
  I think it's fair to talk about optimisation (premature or otherwise) for anything fitting Blum's axioms. The classic ones are number of instructions executed, wall-clock time, memory usage, network requests, user interactions, calls to some slow function (e.g. the comparison function, for sorting algorithms), etc. but I think it's also applicable to fuzzier concepts. For example, modularity could be modelled as the time/edit-distance/etc. it would take to swap-out N out of C components, where C >> N. If we're defining things centrally and passing them around via dependency-injection then it's O(N) (each component is defined once, so change N of them); if we're hard-coding references everywhere then it's O(N*C) since we'll have to check for references in all of the components, and each one needs to be checked for the N possible swaps. On the other hand, dependency injection is less optimal than hard-coding for a metric like API size: for N components, the number of references grows as O(N^2) (since new components need to reference existing ones, and existing ones will need to reference them); so APIs using DI will have O(N^2) arguments.
  - munch117 3y ago
    Fair enough. You can optimise for lots of things. But when people warn against "premature optimisation", specifically, they are advising you to give higher priority to things like modularity, readability, abstraction and maintainability, and not sacrifice them all for a singular goal, typically speed.
hinkley 3y ago
People deal with the cognitive dissonance by calling these optimizations other things, like “architecture”. But at the end of the day, if you’re changing your architecture for any reason other than correctness, then you’re optimizing. And if you’re having a hard time doing it, then you probably waited too long. “The Last Responsible Moment” is subtle. You have to include user benefit (they may not care yet) versus snowballing consequences of delay, versus having more and better information later on. One of the things that drew me to CI/CD was the notion that you’re not going to get better at handling your problems by avoiding them. You can’t learn to pick your optimization battles if you never fight them. You won’t learn something I’ve been saying for almost 25 years now and I still haven’t heard come out of anyone else’s mouth: there are code changes that improve readability and performance. Making those changes as refactors is hardly ever premature.

by _dain_ 3y ago

whstl 3y ago

And the "premature optimization" excuse is used almost every time someone argues that over-abstraction can cause performance issues.

hinkley 3y ago
Or other forms of laziness.

munch117 3y ago

"Premature optimisation" refers to speed or size. Using the phrase to talk about those other things is a stretch. (Except maybe cost.) You can design for modularity, readability etc., but optimising for them doesn't sound right. Something to do with them not having well-defined, agreed-upon definitions of where the optimum is.

hinkley 3y ago
I work with a Principle of Maximum Power guy. He’s insufferable. Too smart to browbeat into behaving, and too old to chalk it up to youthful exuberance or lack of experience. He’s made big chunks of the project comfortable for him and miserable for everyone else, so of course he’ll never leave, and people who know they deserve better do.
chriswarbo 3y ago
I think it's fair to talk about optimisation (premature or otherwise) for anything fitting Blum's axioms. The classic ones are number of instructions executed, wall-clock time, memory usage, network requests, user interactions, calls to some slow function (e.g. the comparison function, for sorting algorithms), etc. but I think it's also applicable to fuzzier concepts. For example, modularity could be modelled as the time/edit-distance/etc. it would take to swap-out N out of C components, where C >> N. If we're defining things centrally and passing them around via dependency-injection then it's O(N) (each component is defined once, so change N of them); if we're hard-coding references everywhere then it's O(N*C) since we'll have to check for references in all of the components, and each one needs to be checked for the N possible swaps. On the other hand, dependency injection is less optimal than hard-coding for a metric like API size: for N components, the number of references grows as O(N^2) (since new components need to reference existing ones, and existing ones will need to reference them); so APIs using DI will have O(N^2) arguments.
- munch117 3y ago
  Fair enough. You can optimise for lots of things. But when people warn against "premature optimisation", specifically, they are advising you to give higher priority to things like modularity, readability, abstraction and maintainability, and not sacrifice them all for a singular goal, typically speed.

hinkley 3y ago

People deal with the cognitive dissonance by calling these optimizations other things, like “architecture”. But at the end of the day, if you’re changing your architecture for any reason other than correctness, then you’re optimizing. And if you’re having a hard time doing it, then you probably waited too long. “The Last Responsible Moment” is subtle. You have to include user benefit (they may not care yet) versus snowballing consequences of delay, versus having more and better information later on. One of the things that drew me to CI/CD was the notion that you’re not going to get better at handling your problems by avoiding them. You can’t learn to pick your optimization battles if you never fight them. You won’t learn something I’ve been saying for almost 25 years now and I still haven’t heard come out of anyone else’s mouth: there are code changes that improve readability and performance. Making those changes as refactors is hardly ever premature.