@irene@discuss.systems - I took a look at your note "Slow Software". I felt that the general notion was quite rational - separating high impact code (and thus give it more care) from lesser impact code. I do testing - I break code. And I've noticed an increasing tendency of builders to presume ever-faster underlying processing, memory, and network resources. I work with the latter - network services going bad. I am seeing more and more code begin to break on low performance platforms - such as cheap Chromebooks - because the code being run presumes vast network resources rather than things like slow connections, intermittent connections, and support for only a few TCP connections at a time. This is exaberated by the new generation of "proof of work" challenges being presented to incoming clients in order to cull bots from humans. An exaple is Apple's Music App - it goes bad, often for quite a while, when the underlying network changes, such as when getting into a car and thus switching from wi-fi to 5G.