Understandingnine days beforeOnce the notion of a problem is sufficiently semantically disambiguated, we can…Cheesecake and Baklava

Asymptotes and Value Niches2023I have been thinking lately about a framing that would help clarify…The protocol force2024Here’s a riff on the “hourglass model” conversation I’ve had with Bernhard…Watch for platforms to emerge2021A recurring theme in my conversations is the question of platforms. How…The rewrite count2021As a software engineer, I often see a struggle that both teams…I have been reading Alex Komoroske’s Compendium cards on platforms, and there’s just so much generative thinking in there. There’s one concept that I kept having difficulty articulating for a while, and here’s my Nth attempt at defining it. It’s about the thinness and thickness of layers.

The cost of opinion2022It appears that I’ve been writing this essay since 2012, never quite…Given that layers have vectors of intentions, we could imagine that the extent to which these intentions are fulfilled is described by the length of the vector. Some layers will have super-short vectors, while others’ are quite protracted. To make this an easier visual metaphor, we can imagine that layers with longer intention vectors are thicker than layers with shorter vectors of intention.

Open-endedness and bedrock2021I’ve been inspired and captivated by Gordon Brander’s exploration of open-ended systems,…For example, check out the 2D Canvas API. A long time ago, back when I was part of the WebKit project, I was amazed to discover that Canvas’ Context API was basically a wrapper around the underlying platform API, the GCContext. Since then, both APIs have moved apart, but even now you can still see the resemblance. If we look at these two adjacent layers, the intention of this particular Web platform API was perfectly aligned with the underlying platform’s API intention and the length of the vector was diminutively tiny — being literally a pass-through. If you wanted to make graphics on the Web, this was as close to the metal you could get, illustrating our point of thinner layers yielding shorter intention vectors.

The Cruelty of Unattainable Perfection2004First, there was pristine perfection: a vision of a mark up language…Graphics and Structural Markup: Keeping “pretties” out of content2005Pet peeve time! Let's talk graphics. You know, the catchy visual dujibobs…Of Men with the Brain on Both Sides and a Utopian Cult2005Has it really been that long since my last post?The Bogeyman of ASP.NET2004Let me first start by saying that ASP.NET is an awesome framework.…To compare and contrast, let’s look at Cascading Style Sheets. It’s fairly easy to see the intention behind CSS. It strives toward this really neat concept of separating content of a Web document from its presentation. When I first learned about CSS, I was wholly enamored—and honestly, still am—with such a groundbreaking idea. I even wrote an article or two or three (Hello, 2005! I miss your simplicity) about best practices for content/presentation separation.

Retained and immediate mode2021With my apologies to my colleagues — who will undoubtedly make fun…We can also see that this vector of intention extends much farther than that of the 2D Canvas API. Especially from the vantage point of a WebKit engineer, if seems like CSS took something as simple (and powerful) as GCContext and then charged daringly forward, inventing its own declarative syntax, a sophisticated model for turning these declarations into rendering, including deeply nuanced bits like formatting and laying out text. CSS is a much thicker layer. It’s the whole nine yards.

Deep Stack Engineer2023Riffing on the idea of layer gaps, we can surmise that pretty…Moving the ladder2022Riffing on the cost of opinion piece, I realized that there’s a…The question that inevitably arises for the aspiring platform designers is “which kind is better?” Why would one decide to design their layer thin or thick? It’s a good question. Now that we’ve learned about the pace layers, we can seek insights toward answering this question through this thought experiment. Let’s pretend to be designing a platform in two alternate realities of extremes. In the first, we boldly decide to go for the cheesecake approach: a single layer that has one vector of intention, fulfilled as completely as possible. In the second, we, just as boldly, had chosen the baklava approach: our layers are countless and are as thin as possible, just like in filo dough. Anybody hungry yet?

AI Developer Experience Asymptotes2023Layer gaps2023

Forces of the pace layering confusion2021I had a super-insightful conversation this week with a colleague about approaches…Applying the pace layer dynamic to both alternatives, we can see that the baklava platform is better equipped to withstand it: the multiple layers can choose their pace and change independently of each other. Poor cheesecake will have a harder time. The single layer will inevitably experience a sort of shearing force, pushing its upper part to change faster, with the bottom part staying relatively still. If I were a poetic kind, I would say something like: “this is how layers are born – in the struggle with the shearing force of innovation.” But even if I weren’t, I can describe it as a pretty significant source of suffering for developers. Especially in monolith repositories, where everyone can depend on everyone and dependencies are rarely curated for proper layering (visualize that dense mass of sugar-laden dairy), developers will keep finding themselves battered by these forces, sometimes even without realizing that they are sensing the rage of pace layers struggling to emerge. Using CSS as the reference point, I remember having conversations with a few Javascript framework developers who were so fed up with the inability to reach into the CSS monolith, they contemplated — and some partially succeeded! — rolling their own styling machinery using inline styles. There’s no good ending to that particular anecdote.

The waterline2023This one is a very short framing, but hopefully, it’s still useful.…Pace layers of predictability2023One thing that stood out to me was this notion of a…Surprisingly, baklava will experience a different kind of force, caused by the same pace layer dynamic. If I design a platform that consists of a multitude of thin layers, I am now responsible for coordinating the moving of the ladder across them. As you can imagine, the costs of such an enterprise will accrue very quickly. I was once part of a project that intended to design a developer platform from scratch. As part of the design, several neatly delineated baklava-like layers were erected, with some infrastructure to coordinate them as they were developed. Despite having no external developers and still being at an early-days stage, the project rapidly developed a fierce bullwhip effect akin to the one in the infamous beer game, threatening the sanity of engineers working at the higher layers. Intuitively, it felt right that we would design a well-layered developer surface from the ground up and keep iterating within those boundaries. It just turned out that there are many different ways in which this layering could happen, and picking one way early on can quickly lead to unhealthy outcomes. Layers accrete. Imagining that they can be drawn from whole cloth is like planning to win a lottery.

The Layering Principle2023Preference toward layering is probably one of the more fundamental principles of…Well, great. Our baklava keeps wanting to turn into cheesecake, and cheesecake keeps wishing to be baklava. Is there a golden middle, the right size for your layer? Probably. However, I have not found a way to determine it ahead of time. Platform engineering is not a static process. It is a messy dynamic resolution of layer boundaries based on developers interacting with your code — and dang it, the “right answer” to layering also changes over time. API layering is inherently a people problem. Despite our wishes to get it “right this time”, my experience is that until there is a decent number of developers trying to build things with my APIs, it is unknowable for me what “right” looks like.

The platform two-step2022When we last saw Uncle Steve on his ladder, I left him…Four layers2023An illustration for how this plays out is the abundance of the…Polarity-based API layering2021While discussing API design, one pattern that caught my eye was polarity-based…Minimum viable legibilitythe day afterHaving seen folks struggle through another Google perf season and supporting them…Shadows and Curseslinks here, 2022One of the common drivers in this transformation to the condition of…Porcelainslinks here, 2023However, as a result of creating this layer, I now become responsible…Declarative vs. imperativelinks here, 2024Therein lies the ancient dynamic that underlies bets (or any value judgments,…AI Baklavalinks here, 2024Putting these two together, I wonder if we’ll see the emergence of…When gearing up for shipping developer surfaces, bring lots of patience. The boundaries will want to move around, evolve, and reshape across the pace layer continuum. Layers will want to become thinner and then change their minds and grow a little cheesecake girth. Getting frustrated about that or trying to keep them still is a recipe for pain. Platform engineering is not about getting the API design right. It’s about being able, willing, and ready to dance with it.