#computing #programming # [[Epistemic status]] #schroedinger-uncertain # [[Philosophy/Rationality/Models/Antifragility|Antifragility]] In [[Hackers & Painters - Big Ideas From the Computer Age]], [[Paul Graham]] says that open source software has less bugs and it make sense, it's like throwing a cat in the jungle, he will get [[Adding shocks|shocks]] from the whole [[Eco-system|eco-system]] and survive or perish, an open source software get attacked from everywhere, [[Pull requests]] are like [[Biology/Sex]] in humans, it's [[Biology/Sex]] [[Memetic|memetic]], codes have sex producing a better code, with less bugs and higher quality, or maybe lower [[Kolmogorov complexity]] (i.e. less code but same results) and higher [[Kolmogorov maintainability]]. Asymmetries: - Testing (to some limits, some test are highly costly, such as integration): unit testing for example is usually easy to implement with the benefit of being alerted whenever you break the code on updates. - Feature decision making: how costly is it to implement this, how much value it brings to the software? Negative asymmetries: - Over-engineering, premature optimisation: We all know the famous quote from Knuth **Premature optimisation is the root of all evil.**, start simple, then improve. ## Chaos Engineering A related idea, chaos engineering, the act of applying nature-like stressors on a software to reveal its fragility. However chaos engineering feels a bit gamified, it's usually only applying failure that you know, i.e. [[Mediocristan]] events, so you can still be fragile to [[Philosophy/Rationality/Models/Black Swan|Black Swan]]. The best way to spot fragility in your software is to actually deploy it in nature, in the real world, in [[Extremistan]]. ## Do not get fooled by the data At **Airbnb**, they realised early that the best fitness functions of their product was produced by asking the customer what they thought, not the analytics data that are gamified. And when you ask a feedback, do not ask precise questions, let the other party think broadly, otherwise you are still gamifying the process. ## Randomness injection In software development, especially in [[Business 🔨]], we often focus on the tasks that brings the most value to the [[Business 🔨]] with the smallest cost. The problem with that way of thinking: - In-human, we are not machines (yet). - Randomness is necessary for **antifragility** - Tinkering produces [[Business/Entrepreneurship/Innovation|innovation]] I find it a good strategy to allocate a part of the time to code whatever you want regarding the [[Business 🔨]].