Internet built on open protocols

The domain name registration isn't as much of an outlier as this author makes it out to be. DNS itself is an open protocol—any server can be queried by any client. The DNS registration process replaced manual host tables on each node, which quickly grew unscalable. There are similar notions of port registration, MIME-type registration, and other registries.

Origin of UDP as the split of TCP and IP

This is the center of the hourglass protocol stack shape.

D. Clark. 1988. The design philosophy of the DARPA internet protocols. In Symposium proceedings on Communications architectures and protocols (SIGCOMM '88). Association for Computing Machinery, New York, NY, USA, 106–114. https://doi.org/10.1145/52324.52336

The Internet protocol suite, TCP/IP, was first proposed fifteen years ago. It was developed by the Defense Advanced Research Projects Agency (DARPA), and has been used widely in military and commercial systems. While there have been papers and specifications that describe how the protocols work, it is sometimes difficult to deduce from these why the protocol is as it is. For example, the Internet protocol is based on a connectionless or datagram mode of service. The motivation for this has been greatly misunderstood. This paper attempts to capture some of the early reasoning which shaped the Internet protocols.

Gall's Law

Gall's Law is a rule of thumb for systems design from Gall's book Systemantics: How Systems Really Work and How They Fail.

It reminds me of the TCP/IP versus OSI network stack wars.

Shaping has four main steps that we will cover in the next four chapters.

1. Set boudaries. First we figure out how much time the raw idea is worth and how to define the problem.

2. Rough out the elements. Then comes the creative work of sketching a solution. We do this at a higher level of abstraction than wireframes in order to move fast and explore a wide enough range of possibilities. The output of this step is an idea that solves the problem with the appetite but without all the fine details worked out.

3. Address risks and rabbit holes. Once we think we have a solution, we take a hard look at it to find holes or unanswered questions that could trip up the team. We amend the solution, cut things out of it, or specify details at certain tricky spots to prevent the team from getting stuck or wasting time.

4. Write the pitch. Once we think we've shaped it enough to potentially bet on, we package it with a formal write-up called a pitch. The pitch summarizes the problem, constraints, solution, rabbit holes, and limitations. The pitch goes to the betting table for consideration. If the project gets chosen, the pitch can be reused at kick off to explain the project to the team.

Two tracks

You can't really schedule shaping work because, by it's very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that's been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment has been made to bet on it.

That gives the shapers the option to put work in progress on the shelf or drop it when it's not working out.

Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There'll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It's that kind of private, rough, early work.

It's also strategic work. Setting the appetite and coming up with a solution requires you to be critical about the problem.

• What are we trying to solve?
• Why does it matter?
• What counts as success?
• Which customers are affected?
• What is the cost of doing this instead of something else?

Knowledge about how the system works will help you see opportunities or obstacles fro implementing your idea.

Shaping is primarily design work. The shaped concept is an interaction design viewed from the user's perspective. It defines what the feature does, how it works, and where it fits into existing flows.

• what the feature does
• how it works
• where it fits into existing flows

When a project is defined in a few words, nobody knows what it means. "Build a calendar view" or "add group notifications" sound sensible, but what exactly do they entail?

Team membres don't have enough information to make trade-offs.

Principles of Shaping

When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes.

Second, we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves.

To manage this new capacity, we switched from ad-hoc project lengths to repeating cycles. (It took some experimentation to find the right cycle length: six weeks. More on that later.)

We formalized our pitching and betting processes.

My role shifted again, from design and product management to product strategy.

I needed new language, like the word "shaping", to describe the up-front design work we did to set boudaries and reduce risks on projects before we committed them to teams.

Don't think of this asa a book. Think of it as a flashlight. You and your team have fumbled in the dark long enough. Now you've got something bright and powerful to help you find a new way.

Founders ask themselves: "why can't we get features out the door like we used to in the early days?" 创始人问自己“为什么我们不能像早期那样把功能推出去？”

At the time I wasa a web designer with a focus on usability and user interfaces. I executed Json's design direction for key features of the app and collaborated with him to fill in details of the concept.

We knew we wouldn't get anywhere with those ten hours of programming unless we used them very deliberately. Our intense focus on "hammering" the scope to fit within a given time budget was born under these constraints.

I learned the techniques programmers use to tame complexity: things like factoring, levels of abstraction, and separation of concerns.

with one foot in the design world and one foot in the programming world, I wondered if we could apply these software development principles to the way we designed and managed the product.

I wore the designer and product manager hats on the project and prototyped the breadboarding and scope mapping techniques described in this book to manage the complexity.

...we redesigned Basecamp from scratch for version 2.0.

We needed language to describe what we were doing and more structure to keep doing it at our new scale.

Network Layer protected by Transport Layer

In the case of IPv4 at the network layer, it is protected by the small number of protocols at the Transport Layer. Even the cannibalization of TCP by QUIC, that is still happening at the Transport layer: [QUIC] does this by establishing a number of multiplexed connections between two endpoints using User Datagram Protocol (UDP), and is designed to obsolete TCP at the transport layer for many applications, thus earning the protocol the occasional nickname "TCP/2"..

Defining the "EvoArch" (Evolutionary Architecture) hour-glass model

The hour-glass model is the way it is because these middle core protocols profile a stable foundation experimentation and advancement in upper and lower level protocols. That also makes these middle protocols harder to change, as we have seen with the slow adoption of IPv6.

The shape of the virus. more detail of the shape

"clay" elicits ideas of rebirth and reformation; a new shape, a new you.

"wattle" as well--is symbolically laden with anatomy connotations, but also can be reference to twings, and other images of nature.

first sighting: shape-outside

practices, geography, time period, class etc. etc.

super helpful summary. Commenting just to tag it.

What is left out is as important to shaping the argument and what is chosen.