[j_h_s]

"the rational behavior would be to read the code, understand what it does, and reject it if it doesn't work for their use case."

This just isn't practical in most cases. I just don't have time to read the source of every tool I use. No matter how much we strive for simplicity, the fact of the matter is that nearly any software system that is useful these days is going to be too big for every developer who uses it to read its source. You have to accept that in a lot of cases, you're going to need to use tools whose inner workings are obscure to you.

Simplicity in programming is great, but we passed the point of understanding all the software we used a LONG time ago.

[nulltype]

The inner workings may be obscure, but I really like it when the outer workings are not. I use the Google Datastore (although Postgres would work here too), which I'm sure is super complicated internally. Externally though, it has certain properties that form a fairly simple mental model.

With that mental model, you can predict from reading some code what the possible error cases or race conditions could be, or what the state of the datastore entity would be after running some code against it. Perhaps that's not precisely "Software Complexity", but "Library Complexity" instead.

I was going to use Redis as an example, but the internal workings are probably too easy to understand.

[vitd]

I concur. In addition to not having the time to double-check everything I run, I don't have a choice of what tool to use in many cases. Either there is no other tool, my employer (or customer, or vender) has dictated that I need to use a particular tool, or other tools are too expensive/run on a different system/whatever.

[joepvd]

Yes. But it is reassuring when a dependency facilitates a relatively painless deep dive into its guts.

Not sure if and how one could know this beforehand, except for taking advise from random strangers in places like this.