3 ms·
I haven't yet read the article, but the title immediately made me think of Paul Graham's Doing Things that Don't Scale[0]. [0] http://paulgraham.com/ds.html ht
by merlincorey 8y ago
I haven't yet read the article, but the title immediately made me think of Paul Graham's Doing Things that Don't Scale[0].
[0] http://paulgraham.com/ds.html http://paulgraham.com/ds.html
- merlincorey 8y agoAfter reading it, it also has some "perfect is the enemy of good" messaging. It also purports that being too efficient (and therefore specialized) reduces agility and can be dangerous by preventing pivoting.
- sitkack 8y agoOveroptimized systems often lose resilience and become fragile. Slop provides a buffer for give and take. This is analogous to materials that have a wide plastic region vs materials that have very high rigidity but a small plastic region.
- deleted 8y ago[deleted]
- fiachamp 8y agoRecalls a fundamental lesson about nature/reality preferring redundancy to the detriment of pure efficiency by Nassim Taleb: https://youtu.be/AcTvkt8k0sE?t=563 https://youtu.be/AcTvkt8k0sE?t=563 Pure optimization is a very ruin-prone path to take over time.
- CJefferson 8y agoI've often seen this with coding -- another reason (if you needed another) to avoid premature optimisation is, in my experience, it often specialises code to a special purpose, and can make it harder to make changes later. Often a simple implementation of an algorithm can be within 10% of the performance of a much fancier one, and is much easier to adapt later to a new use. Even if the less optimal implementation is ten times slower, that still doesn't matter if it isn't on the critical path.