Strictly (well, laxly) Business
This issue is work-centric, but I'll be back to bloviating soon enough. I am, however, really excited about The Nature of Software, plus a couple other items.
The Nature of Software Is Under Way
There are currently 65 paying subscribers to The Nature of Software. This pleases me greatly. If you don’t know what I’m talking about, I’ll excerpt the pitch for you here:
In October 1996, the architect Christopher Alexander spoke to “a whole football field full” of software developers. He told them that patterns—which he and his colleagues had invented, and with which so many software people had become enamored—were fundamentally inadequate for creating the kind of structure he was trying to achieve in the world. He told the audience he had a replacement in the works, and then he asked the software community to help him.
The replacement, which took another eight years to finish, was a four-volume, twelve-pound, 2500-page treatise called The Nature of Order. Merely reading it is a project unto itself, let alone trying to apply it to software development.
Since I have read The Nature of Order—along with pretty much everything else Alexander has written—and know a decent amount about software development, and can apparently string a sentence together, I am offering the service of doing exactly this: applying The Nature of Order to software, and abridging and interpreting it for you, in the form of a twice-monthly newsletter.
The format for this essay is straightforward: The thesis of The Nature of Order is that buildings which people perceive to have what Alexander called living structure will tend to also measurably (and often rather conspicuously) exhibit fifteen particular geometric properties. These properties double as structure-preserving transformations: individual steps of a recursive process akin to morphogenesis. His argument is that buildings done the conventional, planned, Cartesian (read: Waterfall) way can never achieve the saturation of local adaptations needed for living structure; rather you must use what is effectively a fractal process. Sounds a heck of a lot like the state of the art of software development methodology, doesn’t it?
Even the concept of living structure, which sounds a bit mystical and woo-woo when talking about buildings, is totally ordinary talk when referring to software. Consider how so many open-source projects attract people and activity from all over the world, how relationships—jobs, companies, marriages—are forged around these projects, and how quickly software disengages from the world around it if this activity dies off. This actually tracks very closely to what Alexander meant by living structure anyway: structure that promotes ordinary life, and engenders us to take care of it, because in its peculiar way, it takes care of us.
So the program of The Nature of Software is to write a chapter on each of these fifteen geometric properties, and try to translate them one by one to the topological properties of software, as an artifact at rest, as a running executable, and as a development process. As I say in the introductory chapter, I don’t know how well these fifteen properties are going to map—indeed the fifteenness of the properties itself is not terribly important—but the project is to figure that out. Once I’ve done all fifteen, I’m planning on doing at least one conclusory chapter that ties them all together. The ultimate goal of this series, aside from compressing the behemoth that is The Nature of Order by at least an order of magnitude, is nothing short of a practical application of the methodology described therein, that you can use in your own projects.
The first of the properties, Levels of Scale, went out on June 16th. The next one, Strong Centers, will go out next week. I am aiming for two chapters per month, which should mean I’ll be finished sometime in early 2023. The subscription fee is USD $7 per month (i.e., for ~2 chapters). I’d love for you to join us.
My readership goal for this project is 200 subscribers—eminently doable since I’m already almost a third of the way there. If you already subscribe to The Nature of Software, I fully support you forwarding it to somebody you know who would benefit from reading it as well.
Opening The Books For Q4
My consulting practice is apparently nucleating around a semi-repeatable format: what I’ll just call for now a strategic engagement. This is a two- to three-month project aimed to help teams at software and/or digital media companies get organized for a much bigger project they will ultimately take on themselves. Examples of such projects include:
Localizing your entire product line and marketing infrastructure,
redesigning your website,
overhauling your codebase,
even instituting new organizational policy.
How I can help, aside from providing the benefit of an outside perspective that all consultants do, is by concentrating and compressing the various parts and pieces and concerns into a single, compact resource. Activities range from content and asset inventories, to literature reviews, to concept schemes and vocabularies, to tooling and prototypes, to helping the team craft big-picture narratives describing the undertaking. I bring a combination of deep technical knowledge and experience (which I hope I have demonstrated here and elsewhere), with being well-read (ditto), plus a couple things I think that are unique:
Web-first deliverables: I have gotten into the habit of delivering my work product directly on the Web (and I don’t mean Google Docs), specifically on a private extranet. I work out in the open for most deliverables, and I make them available in real time. I also make it a point to ensure that anything more structured than freeform text is marked up so that it is directly computable. That is, you get—for all intents and purposes—a database, for every data-shaped thing generated over the course of the project, along with your documents. This turns out to be handy.
The Specificity Gradient: This is something I have tacitly infused into my work for over a decade, but as I mentioned recently, I’ve started to turn up the volume on it. This reduces to organizing activities and deliverables around concerns of increasing detail, which tends to also track with perishability in time.
Ideally, there’s a team out there interested in doing one of these strategic engagements closer to the end of the year. If that’s you, please do get in contact.
I am also preparing a lighter-weight offering: just the business ecosystem on its own. This is the thing that lives at the chunkiest part of the specificity gradient. Essentially it’s an annotated formal model of your organization, its gross anatomy, and its neighbours, served up as a knowledge graph and imported into your favourite visualization platform. It’s a jetliner’s view of everything your organization interacts with—eminently helpful for improving situational awareness and planning.
Pivot to Video?
At the goading of one Visakan Veerasamy a couple months ago, I have begun, as mentioned, an exercise of doing videos in the mornings, eventually settling on Mondays and Fridays. (Although not this week, because I had a bigger video project planned, and decided doing the regular videos would detract from that.) These are unscripted, and modulo cutting out excess fidgeting or filler words, largely unedited. They seem to reach their natural conclusion at around five, or more often around ten minutes.
I’m already getting a feel for what—in terms of quantity of content, spoken at a reasonable pace—five or ten minutes of talking feels like. That’s kind of a secondary goal to this endeavour. I’m taking inspiration from Patrick Winston’s talk How to Speak, when he says that an informal survey of his peers reveal that a speaker (who is up for a job) has five minutes to make an impression.
YouTube, mind you, is more like two to maybe three minutes. It’s hard to tell exactly though, because they seem to give you the average (that is, the mean) view time rather than the median. (The little time series at the bottom does, however, give you a sense of what percentage of the audience watches the whole way through. Sort of.)
The primary goal of these warmup videos, though, is to practice articulating ideas that are relatively mature. That is, I’ve gotten over the hump of gaining comprehension of a given topic and can speak freely and concisely about it. It’s about sounding out arguments from relatively well-considered positions. Why video? Because aside from what I just said about literally sounding out arguments, it turns out it takes a heck of a lot less effort to go from zero, to ten minutes of video on YouTube than to write the equivalent in text. No really, I’m surprised as well. Note though—at least for the warmups—that I’m deliberately putting the bare minimum production value into them. The longer (but also sometimes shorter) talks will always get more polish.
I am emphatically not at the point at which I get purpose-made lighting, camera, and other accoutrements, though I do have a lavalier.
I promise I will never be one of those “don’t forget to like and subscribe” people, but that said, if you can’t get enough Dorian Content™, you can always subscribe to that too.
Things I’d Like Some Help With
Here are a couple projects that I don’t want to declare stuck per se, but they are definitely moving slowly. I am asking you for ideas, input, or resources:
Getting My Draft to RFC
When I injured my knee back in January, I lost all momentum on everything I was working on for several weeks. One thing I let go was an Internet-Draft for a compact UUID representation. (Turns out, by the way, that letting an I-D expire is not the end of the world; it’s just meant to shame you or something.) When I do get around to reviving it, though, I want to graduate it into an RFC.
I characterize this work as kind of like the digital equivalent of a cotter pin. I’m sure we’re all familiar with what UUIDs look like (3068814d-9371-4600-be32-d70f190a13df), and in addition to being long they also rather peskily start with a number about ⅝ of the time. This means you can’t reliably use them as identifiers, because in most places, identifiers aren’t allowed to start with numbers (or contain hyphens, but I digress). Because of this, people do all sorts of terrible things to UUIDs to make them fit, often at the expense of being able to reliably recover them without some prior knowledge of how they’ve been perturbed.
My contribution, via this I-D, is a shorter representation which is recoverable—because it’s recognizable in the wild—and is guaranteed to start with a letter. The UUID above transformed to my compact representation looks like this: EMGiBTZNxYA4y1w8ZChPfL. What the spec defines is a principled way (there are actually three variants, but no need to strut) to move the bits around.
If you’re interested in using this spec (I use it everywhere), I have an implementation in Ruby, and one in Perl (the original, many moons ago when I still wrote anything new in Perl). What I’m interested in, though, is getting this thing made official. So if you’ve been through the RFC wringer before—or if you are interested in writing a JavaScript or Python implementation—I want to hear from you.
I Wrote a Contract
Okay, so this one is a little bit more ambitious. Back in the fall of 2017, I wrote a master service agreement (most of it on an airplane, sick as hell with a cold), more or less from scratch.✱ I did this because just about every contract I had previously gotten my hands on was written in a way that made assumptions about what was being transacted that I specifically intended to challenge.
✱ By “from scratch” I mean “frankensteined from a pile of contracts I had collected over the years”, but I did write a few key clauses.
Specifically, the service contracts I encountered all assumed that the job is to generate—and moreover to invent—intellectual property for the client. Simply put: no. Intellectual property is a byproduct of the service, and not all intellectual property is created equal. There are works, which are the deliverables the client putatively cares most about. Those are covered by copyright. Then there are inventions, which are covered by patent. If you know anything about patents, you know that they’re worth a hell of a lot more than some lousy pile of internal documents. So I wanted a contract that said under no uncertain terms that the parties agree that during the course of this transaction, nothing is being invented, unless we agree explicitly during some specific engagement to do otherwise. Simply put (again): inventions cost extra.
Patents cost about 300 bucks to file, but another 50 grand to prepare. Software patents are particularly pernicious because more often than not the inventor probably got paid less to invent the thing than the lawyer did to prepare the filing. So the way I see it, I deserve at least—at least what the lawyer makes—to assign a patent for any invention of mine, and there’s a good argument to be made for at least two orders of magnitude more than that. But between you and me, I’d prefer nobody patents my software, because software patents are inherently predatory bullshit.
I should also add that I have a clause for trademarks in there too that says more or less that the client has right of first refusal over any trademark-able symbol they find in the work product, again unless the engagement involves specifically coming up with a trademark.
The contract also provides for two grades of information security: confidential, which is like “take the ordinary precautions and don’t blab to anybody”, and sensitive, which is like “our business is in serious danger if any of this gets out”. The purpose of this is to force discussion and protocols around precisely what information gets shared, and what security—not to mention insurance—precautions are necessary. Also, the vast majority of the projects I work on are totally non-destructive: if you don’t like the result, you can just ignore it. The boilerplate, therefore, says that there is no liability for errors or omissions beyond a refund, again unless an exception is made for a specific engagement.
This is also part of the point of having the agreement split into a master document that governs a longitudinal relationship, with specific provisions for amendments in the schedules that actually authorize exposure to risk and exchange of value. That way, we can conceivably greenlight a project with a mandate that would fit on a Post-It, but more to the point, it forces us to acknowledge—and compensate for—any salient risks before any sensitive material changes hands.
Maybe this is the paranoid infosec professional in me talking, but in my experience, IT engagements either break in the direction of being totally safe, or otherwise require level 4 hazmat precautions. And if an engagement does require such precautions, the work that requires them can be isolated from the work that doesn’t.
What I’d Like To Achieve
I have not published this contract anywhere. Yet. But my long-term goal with it is to do for service contracts what Creative Commons does for copyright licenses: sensible defaults with pluggable features and jurisdiction-specific adaptations. Moreover, even a modicum of exposure to Creative Commons licenses means you can recognize a code like CC-BY-NC-ND and know what it entails, and in that way they have heavily compressed the vagaries of open-source copyright licenses by effectively creating a protocol for them. I would like to do the same, but for service contracts.
If I recall correctly there are people already doing this, but I appear to have misplaced the reference. Anyway, the last time I checked, they were still making the same assumptions I outlined above, and so just like the points of departure for the GPL, BSD, MIT, Mozilla, and Apache software licenses are all different, so is mine with respect to service contracts.
So, what I am considering, pending community interest, is some kind of funding structure to pay a lawyer to marshal this endeavour, as well as partner with at least one law school, because this has benefits that stretch way beyond my own paltry little enterprise, and there is no way I am paying for it all myself. The product I envision is a skeleton—and here I will disclaim that you should always consult a lawyer before deploying some random contract off the internet—for the kinds of service contracts that assume by default the lowest possible risk exposure, and require us to assess risk on a per-engagement basis.
I would like to thank Amanda Levendowski for graciously pointing me in the direction of law school contract clinics, which prior to her intervention I was not aware were even a thing. I did try submitting to one, but my proposal didn’t rise above the noise. There is only one clinic opportunity per school per semester, so I conclude that enlisting a law school to help with this challenge will probably take considerably more planning and relationship-building. (I’ve never been good with cold calls, anyway.)