The Tip of the Iceberg
A Personal Reflection on the Writing Process
As we enter our fourth year of running Systems Approach, LLC, we take another look at what goes into the process of producing technical books. How do we decide to focus on one topic versus another? There is more to this than just “write what you know” (actually a hotly debated piece of writing advice) as Larry explains below.
In our last newsletter, Bruce gave a retrospective of the last three years of our Systems Approach journey. This week I thought I’d chime in with my thoughts on how it is we decide what to write about. In many ways, this is no different than a researcher picking a problem to work on, a programmer deciding to build a new system or app, or a novelist deciding their next book project. It's mostly about personal tastes, but also includes an element of opportunity (e.g., to leverage some unique experience).
You can see these elements in the First Edition of our Computer Networks book. I had found the organizing principles of networking—along with the practice of building network software—to be a rewarding research avenue. Seeing Tanenbaum’s book as the current (in 1994) state-of-the-art in network textbooks, I realized that there was an opportunity to have impact by putting the Internet architecture front and center. The leverage was that I had spent time working on the TCP/IP stack (and adding RPC to the mix), so I had a strong sense of how everything worked in practice. It was only after I got started that I understood (a) how daunting the task was, and (b) how many blind spots I had about the technology I was trying to write about. Fortunately, Bruce saved the day by joining me as co-author.
That 1st Edition made heavy use of the x-kernel (my research project at the time) to illustrate how various protocols are implemented. That turned out to be a bootstrapping process: it provided the grounding that made it possible to speak with some authority about network systems, but (virtually) no one wants to learn about some obscure research OS as a prerequisite for learning about the Internet. The x-kernel all but disappeared in later editions, but the experience did teach me a valuable lesson, which I’ve come to think of as my version of the Hemingway Iceberg Theory:
Hemingway said that only the tip of the iceberg showed in fiction—your reader will see only what is above the water—but the knowledge that you have about your character that never makes it into the story acts as the bulk of the iceberg. And that is what gives your story weight and gravitas. (Jenna Blum, 2013)
(I also appreciate Hemingway’s writing style, which shares much with technical writing: short/direct sentences and short/focused paragraphs. But I attribute the short-paragraph rule to Ms. Penny Wika, my high school journalism teacher, who insisted that the lead paragraph of any story be no more than 25 words, and never, ever start with “The” or “There”. I often break both rules, but doing so always weighs on me.)
I should bring this back to writing textbooks, but before I do, I can’t help but observe that even technical writing, while unlikely to be mistaken for a novel, can still include a narrative. In the books Bruce and I write, the narrative is just as important as the factual details. You can find the latter anywhere; it’s the former that helps you understand how to think about that information. In research papers the narrative is heavily prescribed—in systems, for example, it’s: (1) Introduction, (2) Design, (3) Implementation, (4) Performance, (5) Related Work. With textbooks you get a little more leeway to craft the narrative, and weave multiple themes through the text.
The key to a narrative is part organizational structure and part knowing what to omit, the latter being a challenge I elaborated on in an earlier post. It turns out the Iceberg Theory and knowing what to omit are two sides of the same coin. Having a real system underpinning a book—and being selective in how much detail you expose—is critical to constructing the narrative. A real system provides the depth you need to talk about abstract concepts, and it helps fill the gaps between the architectural elements. Both are essential if you’re going to try to construct an end-to-end narrative for the reader.
Books Series
Since starting our Systems Approach endeavor three years ago, we’ve produced four books on relatively narrow topics. There’s a unique case for why we selected each of these specific topics, but what they have in common is that each was (1) co-authored with a domain expert, and (2) backed by open source implementation. I’ve come to believe both are essential: you not only need to have someone in the know to ask questions of, but you also need to know what questions to ask (and trying to understand code is a great way to fuel the latter).
Starting with the most obvious choice of topic, our SDN book is a natural continuation of our earlier interests: it describes an approach to implementing network software. Coupled with Bruce’s and my being in the thick of the industry building out SDN products and platforms (at Nicira/VMware and ONF), this made SDN an obvious candidate to write about. Having up-close access to a complete software stack—from programmable data planes, to network operating systems, to a range of control applications—gave us a unique perspective. No matter where you come down on the commercial viability of SDN, the kind of exposure the book gives you to the construction of network software is, in my judgment, essential to understanding networks.
Our Edge Cloud Operations book is probably the least obvious choice in the series, especially if you’re expecting Internet-focused topics. But my experience working with network operators convinced me of two things: (1) that the Internet is rapidly evolving into a set of cloud services, and (2) being able to operate these services is the chief challenge facing the industry. That’s still a tough sell in academic settings (where cloud operations is just the latest incarnation of network management, another neglected topic), but that doesn’t—again in my judgement—make it any less true. It also happens to be a rapidly evolving space, with countless offerings (both commercial and open source) vying for mindshare. And quickly stepping into that gap, today’s cloud providers say “Don’t worry about this problem; it’s really hard, so we’ll take care of it for you.” Personally, that is the loudest invitation to write a book that I can imagine.
Our 5G books (the original primer and our more recent Private 5G book) were born out of the frustration of trying to understand the mobile cellular network. Initially this frustration was due to the many acronyms I encountered, but the closer I looked, the more the problem turned out to be one of trying to internalize a system that had evolved within an entirely different framework. There simply was no easy way to map the elements behind those acronyms onto a framework that made any sense to me. In 5G, the mobile cellular network is trying to redefine itself as a cloud service, which does at least provide a shared language (complicated by subtle differences in our definitions for terminology in that language). Sorting all of that out is essentially what our Private 5G book is about.
Finally, our TCP Congestion Control book is different from the other three, each of which could be characterized as covering an emerging topic. In contrast, TCP congestion control goes back over 30 years. But it is the one hard problem in networking that continues to demand attention even as the overall landscape changes. This makes it worth understanding.
Whether these four topics turned out to be the most useful to write about—or just satisfied our own personal interests—is difficult to say. We can say that our books are among the top non-sponsored search results for their respective topics and the online versions collectively received thousands of visits each week. That’s gratifying, and helps motivate us to look for the next itch to scratch.
Our Systems Approach books are always freely available on GitHub and as web versions, but we also make them available via print-on-demand and as eBooks. For the latter, we occasionally make a second printing available when the amount of new content becomes large enough, and last week we reached that milestone for our Private 5G book with an expanded Appendix on deploying 5G using Aether. It’s currently discounted at both our site and Amazon.
The massive outage at Australian telco Optus continues to be analyzed and led to the resignation of the CEO. The Optus submission to the Australian government was notable for its catalog of large failures by other telcos, a classic “everyone does it” defence. And you probably don’t need us to tell you about what happened at OpenAI last week, but Gergely Orosz at The Pragmatic Engineer has a good overview.
Image this week by 66 north on Unsplash.