Nice perspective! And appreciate an actual use case of what the author is recommending being attached. In my experience, a lot of ills in software come from th

Nice perspective! And appreciate an actual use case of what the author is recommending being attached. In my experience, a lot of ills in software come from the working set of facts around a particular problem becoming too large for one person to hold. Then you get Healthcare.gov v1 -- everyone proceeds on incorrect assumptions about what their partners are doing/building, and the resulting system is broken. As a salve to that problem, napkin-math upper/lower bounds estimation can be incredibly useful. Especially because in system design "the exact number" is usually less important than "the largest/smallest likely number" and "rate of growth/reduction". Simplifying things that aren't useful to know in detail (e.g. the exact numbers for author's users) leaves time/mental space for things that are (e.g. if it makes sense to outsource a particular component to SaaS).