[carbonguy]

Extremely high-quality work here - I spend (what I think is) a significant amount of time trying to understand systems, in general and in detail, and this feels on first reading like something I'll be referring to repeatedly in future.

Already it suggests a surprising idea, which may or may not be fleshed out elsewhere, that a good way to understand an existing system is to try and solve the same problem without reference to how the existing system works:

> You will often expend more cycles understanding the existing design than you would solving the problem from first principles. ...

> Even good solutions can bias your thinking towards a particular part of the design space. ... A great time to look at other systems is after the Design phase, to see if you can map those solutions to your space. Even better, you can often reverse-engineer the details of solutions simply by understanding where they fit in your design space.

If it doesn't already exist somewhere else, we can call it Balakrishnan's Law - the best way to understand a problem is to solve it!

[prmph]

True, this is why I sometimes prefer not to look too closely at the state of the art when addressing a new system architectural problem.

By trying to solve it from first principles, and making some progress but most likely failing to completely solve it, I get a good sense of that the design forces and challenges are. Then, when I go back to study the state of art, I'm much better placed to understand what I'm studying.

Another good thing about this approach is that I minimize pre-biasing my thinking by what is out there now. Then, when studying existing afterward, solutions, I can more clearly begin to see gaps in them that I can direct my efforts to solving.