<aside> 📖 Cover Illustration: Fate of the Animals, by Franz Marc
</aside>
“Demosclerosis isn’t a problem you solve It’s a problem you manage.” Jonathan Rauch, DEMOSCLEROSIS The Silent Killer of American Government, 1994
F.K.A. Amdahl’s Corollary
The most efficient way to implement a piece of software is to do it all yourself.
No time is wasted communicating (or arguing); everything that needs to be done is done by the same person, which increases their ability to maintain the software; and the code is by default way more consistent.
Turns out “more efficient (alt effective)” doesn’t mean “faster (both in performance and time to delivery)”. When there are more people working on the same problem, we can parallelize more at once.
When we break work up across a team, in order to optimize for the team, we often have to put more work in, individually, to ensure that the work can be efficiently parallelized. This includes explaining concepts, team meetings, code review, pair programming, etc. But by putting that work in, we make the work more parallelized, speeding up and allowing us to make greater gains in the future.
Amdahl’s law can be formulated as follows:
In other words, it predicts the maximum potential speedup (Slatency), given a proportion of the task, p, that will benefit from improved (either more or better) resources, and a parallel speedup factor, s.
To demonstrate, if we can speed up 10% of the task (p\=0.1) by a factor of 5 (s\=5), we get the following:
$$ S_{\text {latency }}=\frac{1}{(1–0.1)+\frac{0.1}{5}} \approx 1.09 $$