Comment by _benton
I like Ousterhout's the best because I think it's the most concrete out of the three. The other two are more subjective imo, of course still very useful and important.
Although I think "dependency" is an overloaded term. There are dependencies as in libraries or shared code, and then there are "dependencies" which are like assumptions about other parts of the system. Hickey also mentions this when he talks about interfaces. If you break a class into two classes, but they both make assumptions about the other, in effect they are still the same class.
Perhaps another way to think about complexity is the number of assumptions baked into a system?
When I think about a system that makes zero assumptions, I imagine it would have a large number of configuration points, where every single aspect of behavior and interaction must be specified explicitly instead of implicit and assumed. That sounds complex.
On the flip side, a counter-example comes to mind: automatic imports ("autoloading") in some languages, which makes things apparently simple but gets gnarly when things break unexpectedly. It makes a lot of assumptions about your intention, which is simpler when it works the way you expect. I'd prefer explicit imports every time, even if it's verbose (some might call "complex") because it makes no assumptions - every import is visible so it's actually simpler to understand.