I feel like I've developed all these micro-tactics for making and finding software that meets this standard https://hachyderm.io/@dubroy/111658490778296619 like
- stuff that's written in C and uses a Makefile tends to work like this
- "single-file libraries"
- stuff that is 20+ years old and hasn't been updated but has elaborate API documentation/header comments
- PHP and MySQL: stack that has been stable for a long time, has lots of legacy software written in it, is 'part of the platform' to the point where you don't even need to stand it up on shared hosting
I think Amit Patel (https://www.redblobgames.com) originally got me onto this way of thinking -- he would talk about how he'd learned to avoid build systems as much as possible when writing his interactive articles
because he'd revisit them 5/10/20 years later and find that anything with a build step was now impossible to edit (you can't run the node or Python script on your computer 10 years later, the package dependencies are broken/incompatible, ...)
Amit led me to a similar distinction around the edit cycle of a system: systems like facebook.com which are like engines being updated and maintained by engineers every day, vs. a redblobgames article that might get one edit in five years
(and how we often end up w/ tools that are brought forward by big companies and optimized for the former case: https://hopeinsource.com/emotional/#t=07:04)