Happy new year, everybody. This is my first opportunity since the first of December to get anything written down, so I’m going to need you to pretend it’s at least two weeks ago. (I really wish it was still two weeks ago.)

Method & Structure

Since it’s a new year, I’m going to take the opportunity to remind everybody what I actually do. I offer strategic design and planning support to people who make software, or are just trying to navigate the software procurement landscape for their organization. I do this through my tiny little consulting brand, Method & Structure.

I am the kind of person you call for problems that don’t have an off-the-shelf solution:

• Trying to give a bad SaaS vendor the boot? I can help with that.
• Need to audit your app—​or somebody else’s—​for privacy? There are ways.
• Designing a universal data format for a multi-platform internationalization strategy? Book a call.
• Do you have a bunch of legacy content that needs to be cleaned up and organized? Say hi.
• Is your boss pressuring you to integrate AI, but you don’t want to be in Sam Altman’s pocket? We’ll figure out a path forward.
• How about digital sovereignty? I have an idea or two.

What kinds of problems? Well, the kind a mutant hybrid of UX designer and software developer, with generous splashes of product, process, and information security can help you solve. I’m also big into open protocols and data formats, open-source software, and the structured data specifications that in the biz we call ✨ontologies✨. My superpower is that I read all the boring specs and standards and academic papers that your team is too busy and/​or insufficiently masochistic to read themselves, and then I come up with creative ways to communicate the highlights. Hire me, and your team can get back to doing whatever you hired them for.

This year, especially with the insinuation of AI-as-a-service into every product under the sun, and the exposure that organizations outside the US are starting to feel around their dependency on American tech companies, I’m thinking a lot about both the design and procurement of software-based systems for our new reality. If you’ve been thinking about what this means for your organization, then kindly reach out.

I’m also setting up a new newsletter for Method & Structure, where I’m going to try to direct all my practical, professional, and technical output. There, I’ll be announcing a set of technical seminars for Web development teams, based on technique I developed in the creation of Sense Atlas, my software tool, and its application server, Intertwingler. I’m calling the theme Semantic REST.

Look out as well for upcoming “in the lab” stuff:

• Value-based project planning: Stop estimating time, which is hard, and start estimating value, which is easy (or at least much easier).
• Organizational cartography: Hire me to make maps of your business ecosystem—​and teach your team how to make them too.

Both of those are going to make heavy use of Sense Atlas, which can always use more contact with real clients and their challenges, so there are deals to be had.

So do subscribe to the M&S newsletter for those updates. And, if you have a challenge you think I can help with, you can always book a call.

Software Updates

You may or may not be aware that I have two—fairly major for one person—software projects on the go:

• Sense Atlas, which is a planning tool and attendant knowledge graph,
• Intertwingler, the application server that provides the substrate.

I have plenty to say about both, and from now on, I’m going to be doing most of that over in the new Method & Structure newsletter. For now, I’ll just outline the core ideas underpinning both of these products.

Sense Atlas

Here is a video from June 2025, a month after I put Sense Atlas online.

Sense Atlas came about because I wanted to be able to “tweet” the structure of complex design problems, and record the concerns of all stakeholders in a reliable location that everybody can see and deliberate on. I then wanted to be able to take that resulting structure, and use it—​programmatically—​for all sorts of things like scoping, project planning, and bug tracking.

At the core of Sense Atlas is a graph structure. Not like pie charts, but the network-shaped class of mathematical objects that consist of nodes in a space connected by arrows. The world seems to be finally waking up to just how useful these structures are, and there are plenty of tools out there that implement them, some more conspicuously than others. Why I still felt Sense Atlas was necessary, was a focus on the actual data it produces. There are two aspects in particular of foremost importance:

• Computability: Incumbent graph tools tend not to have a type system, so when you use them, you’re basically making artifacts exclusively for human consumption. In other words, you spend a lot of time almost creating an extraordinarily powerful asset—​data you can use to drive a computer, at least without the headache of costly preprocessing—​but fall short for want of formal data semantics.
• Permeability: Most of these tools don’t imagine a world outside their confines, or after they’re gone. I actually suspect this is a major impediment to adoption for this class of tool in general: it’s a bubble that you have to manually keep in sync with the outside world. The bet is that a system that is amenable to being fed by automated processes, and generally interlacing better with the rest of the world, will fare better. This is why it was essential to create Sense Atlas on top of a foundation of open data standards.

Sense Atlas is still pretty nascent, but I’ve been using it increasingly since I put it online last May. I have also been setting up private instances for certain people. Also, if you’re a client of mine, you get an instance of it on your client extranet.

If you go and look at Sense Atlas, you might notice that it’s pretty slow to load initially. This is because I’m doing something fancy with internal caching in Intertwingler, and haven’t finished that yet. Most of the outstanding work on Sense Atlas that isn’t UI—​of which there is plenty, to be sure—​is actually work on Intertwingler.

When I put Sense Atlas online, I figured it’d be about a year before anybody on the internet could saunter up to it and plug in a credit card. That might still hold? We’ll see. In the interim, it’s serviceable enough to use with clients, and you can always become one of those.

Intertwingler

Intertwingler came about—​mostly—​because I wanted to make a tool like Sense Atlas. The rest of it is an accumulation of opinions I have accreted from 30 (‼️) years of working with the Web.

That surprised me too, but 2026 is my 30th anniversary of making my first webpage.

We could have had Intertwingler over a decade ago, but I hesitated for years before finally acquiescing to write it. Why do we need another Web framework? I thought. Well, the answer is it’s trying to reconcile the Web in practice—​and this is not a misprint—​with the Web in theory:

• Durable addressing: A tool like Sense Atlas is made up of a ridiculous number of very small objects, connected together by an even more ridiculous number of links. That’s a lot of URLs flying around, getting copied and written down in places you don’t control. It’s essential that something is policing these, making sure they don’t rot. Intertwingler treats links as first-class citizens, mapping durable identifiers into the more mutable HTTP URLs we’re familiar with, and remembering every URL every resource ever went by.
• Durable interface: There’s no reason in principle we can’t have software-driven systems that last for decades. The “technology moves sooo faaaast” story is really one about products and their proprietary interfaces. An interface based on open standards is the most robust way to get systems that survive any particular vendor. A uniform interface, furthermore, means there’s only one thing to learn and implement. The goal is to Lego-ize this interface, so you can focus on content, while Intertwingler takes care of the REST.
• Durable system: When it comes to computers, we’re inured, every few years, to throw everything out and replace it. Every time we do this, we lose knowledge and expertise, and we have to learn it all over again. A durable system, by contrast, is one you can repair. It has the ship-of-Theseus quality: if a single board rots out, you can replace just that board. If you replace all the boards one by one, even if none of the originals remain, it’s still the same ship. A goal of Intertwingler is to make extremely crisp definitions of its components, not only so new ones can be created, but also that each can be swapped out in isolation, including Intertwingler itself.

To briefly reflect on why I called this software Intertwingler, it’s because I actually think the Web, being the path of least resistance, has dulled our expectations of what hypertext can be. The name is, of course, a reference to a term coined by Ted Nelson—​the inventor of the concept of hypertext—​that has to do with everything being deeply connected to everything else. This is actually surprisingly hard to pull off with the Web—​and have it stick around and not break—​so I found myself creating an entire application server just to manage it. This is all to say that I’m Intertwingler will be a powerful platform for software, but what I really made it for was to do art with it.

I should also note that even in its current state, Intertwingler is about 80% of an ATProto PDS. One thing I am definitely going to try to do this year is see what it takes to create the necessary adapters to speak that protocol. The motivation for this is somewhat academic, but a “protocol-agnostic” personal data server would be an existence proof that an information system can survive even a change in standards—​as long as you can preserve the data semantics. Plus, it dovetails with my own plans for federating Intertwingler, which I will have to get into in a future discussion.

Intertwingler is a “speaking artifact”—​it’s my Platonic ideal for how the Web ought to behave, but it’s also intended to function as a real load-bearing piece of software. It’s still pretty rough, but I’m hoping I can get other people interested in using it. My goal is to clean it up and get an installation candidate out this year. Updates will be going out on the Method & Structure newsletter.

Newsletter Re-Org

Something I have struggled with for years is how I seem to have no fewer than two distinct audiences with roughly similar interests, who nevertheless exhibit mutually incompatible preferences on focus. For lack of a better term I’ll call this the “technical divide”, where I’m defining “technical” as “the details of how things work”. In my experience, there’s one segment of my audience who’s allergic to these details, and another who insists on them. Reality is even murkier though, as few actual people belong strictly in one bucket or the other. So the question stumping me for years, has been how do I cater to the superposition of these audiences, without compromising the integrity of what I’m trying to say?

To be sure, it’s the reason I got interested in hypermedia, and one of the major motivating factors for creating Intertwingler.

The Format

I’ve remarked before that while I understand (and grudgingly accept) the role e-mail newsletters play in our contemporary media ecosystem, as a format it only occasionally coincides with how I prefer to communicate:

• There’s the throw-away quality of e-mail in general,
• plus its sharp constraints versus an equivalent page on the Web,
• and its tendency to favour linear narratives.

This is against the backdrop of text in general being increasingly harder to sell, especially if it isn’t short and highly visually punctuated. Sure, people can and do publish successful long-read newsletters on evergreen subject matter, but the format is always going to favour quick-hit insights on contemporaneous topics.

And yes I spell it “e-mail” because I speak French and “émail” will never not mean enamel to me. 💅

The Channels

So we’re now up to three newsletters (and counting):

The Making of Making Sense

You’re reading it now. The original idea behind this newsletter was to occupy the gap between Twitter (now mainly BlueSky and to a lesser extent Mastodon), and the heavier-duty articles on my website. I nevertheless keep using it to (accidentally) put out 4,000-word thinkpieces instead. So what I’m going to do is hive off the more narrowly professional and technical stuff, and keep this one as a sort of general catch-all for contemporaneous things-I-noticed, and as a backup channel for the longer-form essays.

I have also enabled premium subscriptions on this channel, with the caveat that I’m not sure what to do with it yet, so consider it pure patronage. It’s pay-what-you-want, with a floor of \$7 a month just like the other two. Those, though, since they are nominally “for work”, are fixed and outfitted with a discounted annual rate for the ol’ company card. Keep reading to see why I did that.

The Nature of Software

The Nature of Software is a serialized book project I began some months after the passing of the architect, Christopher Alexander. The idea is to step through each of the fifteen properties and structure-preserving transformations described in Alexander’s four-volume magnum opus, The Nature of Order, ruminate on how each one might apply to software development, and then synthesize it into a set of properties that are software-specific. I’m about halfway through, but I haven’t written a new chapter in a while.

What happened, more or less, was that my work on TNoS got, uh, intertwingled, with my work on Intertwingler. The Web version at the.natureof.software, like all my other websites, runs on Intertwingler’s static-site-generating precursor. I had a brain-genius plan to dogfood TNoS by moving it over to the live dynamic version, wherein I could start augmenting it with structured data and live annotations. The plan was to eventually grow it into a “permeable” online community where subscribers could add to it and reuse the structured data for their own purposes. Just to be clear, I am still totally going to do this.

I probably should have paused TNoS, but if I had, I doubt I would have started it back up again. Moreover, I don’t think I’ve ever experienced a project with a harsher case of one-more-thing-itis than Intertwingler. For a while, I was routinely finding myself recursively having to invent a whole bunch of things I hadn’t even anticipated. Ironically, the #1 thing I wanted Intertwingler for was the tool now called Sense Atlas, which is a planning tool, specifically designed for capturing the intricacies of novel software development. In other words, the thing that would have eliminated a lot of the uncertainty developing Intertwingler, was the very thing I was trying to make. Now that Sense Atlas is far enough along, I can use it to plan the development of Intertwingler, as well as itself.

At any rate, I’m going to be sending off an “interlude”, i.e., not-a-chapter email in a few days to TNoS subscribers, about the experience of trying to apply Alexander’s later methods to an actual piece of software. I’ll be following up with chapter 9 (Contrast) a few weeks after that. So do subscribe to that if you’re interested.

Just to reiterate, though, The Nature of Software is for paid subscribers.

The Method & Structure Newsletter

The new newsletter I’ve spent this whole issue hawking is my attempt to partition the practical content, which is about concrete problems around information-wrangling in the 21st century and how to solve them, from the more personal and/​or cerebral matters. Here’s what I’m thinking:

• Announcements related to consulting services,
• Practical insights for software and digital media insiders,
• News about Intertwingler and Sense Atlas,
• Technical articles you can use at work.

My inclination is to make the technical stuff premium, unless I take things in the “business intel” direction. You don’t need to make any decisions right away—​I sure as heck haven’t! But you should at least subscribe if this is your kind of material, because from now on that’s where it’s all going to be.

The All-Access Passport

As mentioned, I’ve opened up premium subscriptions on both this and the M&S newsletter, for parity with The Nature of Software, which has always been pay-only. However, I’m going to implement a “passport” system of sorts, such that if you’re a premium subscriber to any one of these three, you also get premium access to either or both of the other two if you want it. Just subscribe, and it’ll automatically hook you up.

Or, at least it will in a week or so. I haven’t set this up yet, but I’ve made a date to be hack this out with the Buttondown API. I’m doing this in the first instance because I think it makes the most sense, at least for the time being, to pair the economic relationship to my output as a whole rather than treat each newsletter as a distinct product. It’s also because after talking to a few Nature of Software subscribers, some of you folks seem to understand that that’s what you’ve been doing all along anyway (and I thank you for that; it’s really helped).

Future Directions

The e-mail address you use for this passport will also get you into any companion sites I stand up, like the.natureof.software. As Intertwingler matures, I’m envisioning it becoming more of a centre of gravity, so I imagine myself eventually threading newsletters much more with content from the Web, powered by Intertwingler (potentially via Sense Atlas). This will be a slow progression, and there won’t be much to do there right away, but you’ll be the first to know about it.

Footnote: I released a video last week meditating on how system-y things tend to eschew conventional “use cases” in favour of predictable constraints in their behaviour. It's fun; watch it.