First, few of the laws on that site are actual laws in the physics or mathematics sense. They are more guiding principles.

> complexity is not a function of time spent working on something.

But the complexity you observe is a function of your exposure to that complexity.

The notion of complexity exists to quantify the degree of struggle required to achieve some end. Ousterhout’s observation is that if you can move complexity into components far away from where you must do your work to achieve your ends, you no longer need to struggle with that complexity, and thus it effectively is not there anymore.

I think the intent is that if you can cleanly encapsulate some complexity so that people working on stuff that uses it don't have to understand anything beyond a simple interface, that complexity "doesn't exist" for all intents and purposes. Obviously this isn't universal, but a fair percentage of programmers these days don't understand the hardware they're programming against due to the layers of abstractions over them, so it's not crazy either.

It's showing that all the complexity in the components are someone else's problem. Your only complexity is your own top layer and your interface with the components.

> Unless you are the one having to maintain that library. Then it just migrates the complexity to another location.

No, it’s a win, even then.

Say you are writing an operating system, and one of the fundamental data structures you use all over the place is a concurrency-safe linked list.

Option 1 is to manipulate the relevant instances of the linked list directly—whenever you need to insert, append, iterate over, or delete from any list from any subsystem in your operating system. So you’ll have low-level list-related lock and pointer operations spread throughout the entire code base. Each one of these operations requires you to struggle with the list at the abstraction level and at the implementation level.

Option 2 is to factor out the linked-list operations and isolate them in a small library. Yes, you must still struggle with the list at the abstraction and implementation levels in this one small library, but everywhere else the complexity has been reduced to having to struggle with the abstraction level only, and the abstraction is a small set of straightforward operations that is easy to wrap your head around.

The sole difference between the options, as you wrote, is that “the complexity just migrates to another location.” But which would you rather maintain?

That was Ousterout’s point.