One that is missing is Ousterhout’s rule for decomposing complexity:

    complexity(system) =
        sum(complexity(component) * time_spent_working_in(component)
            for component in system).

The rule suggests that encapsulating complexity (e.g., in stable libraries that you never have to revisit) is equivalent to eliminating that complexity.

▲ stingraycharles 8 hours ago | parent | next [-]

That’s not some kind of law, though. And I’m also not sure whether it even makes sense, complexity is not a function of time spent working on something.

▲

tmoertel 8 hours ago | parent | next [-]

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.

	▲	wduquette 7 hours ago \| parent [-]
		And in addition, the time you spend making a component work properly is absolutely a function of its complexity. Once you get it right, package it up neatly with a clean interface and a nice box, and leave it alone. Where "getting it right" means getting it to a state where you can "leave it alone".

▲

CuriouslyC 6 hours ago | parent | prev | next [-]

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.

▲

Brian_K_White 7 hours ago | parent | prev [-]

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.

	▲	skydhash 5 hours ago \| parent [-]
		Only when the problem has been resolved well enough for your use cases. Like using an http client instead of dealing with parsing http messages or using a GUI toolkit instead of manipulating raw pixels. That’s pretty much what good design is about. Your solve a foundational problems and now no one else needs to think about it (including you when working on some other parts).

▲ someguyiguess 5 hours ago | parent | prev [-]

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

	▲	tmoertel an hour ago \| parent [-]
		> 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.