Discover more from The Making of Making Sense
In which our intrepid protagonist really steps in it.
First things first: I have a half-written chapter 5 of The Nature of Software that’s been sitting on my desk since Halloween. I shelved it to take care of something that I had anticipated would take a week (it initially looked that way) but ended up tugging on a thread that unravelled half a dozen others, and I’m only finally, finally wrapping those up—amid these endogenous distractions, plus some exogenous ones as well. So I thank you for your patience.
I come from Vancouver, where you can get by from one year to the next without a serious winter coat (umbrellas, on the other hand, are a different story). I am now, and for the immediate future, in a climate zone where you genuinely need one at least a couple months out of the year. So, last Christmas, flush from completing a decently-sized job, I bought myself one. It is easily the single most expensive piece of clothing—really, arctic survival gear—that I have ever owned.
Thanks for reading The Making of Making Sense. Subscribe for free to receive new posts.
Two weeks ago, a busser at a restaurant slipped and dropped a bowl of sour cream onto it. Now, shit happens, and the management was really professional about it, and I sent the coat out to be cleaned at the earliest opportunity—as we were expecting a snowstorm the following weekend.
I want to interject here briefly to say that I’m not taking to my newsletter to air my customer service grievances—I actually have a salient point or two about what it means for we who make software and digital media.
When I got to the singular company listed by the manufacturer as officially-sanctioned cleaners (the closest location of which, it turned out, was a 40-minute subway ride each way), I was taken through a detailed intake process (clearly designed to be CYA; reminded me of what it’s like to rent a car, but whatever, let them do their thing). I made explicit mention of the sleeve with the stain on it, which is the reason why I’m there. They say come pick it up Thursday, I say fine, I get a text on Wednesday to pick it up a day early, I say great. I truck back out there to find a coat with a huge sour cream stain every bit as prominent as it was when I dropped it off, and politely decline to accept the job as completed.
Here, the clerk (a different one) does something that the first one did not: she wrote a note on the bill for the new order to pay specific attention to the sleeve where the stain was.
Here perhaps is where my dry cleaning naïveté shows: I didn’t realize this is something you had to do; I thought you could just drop off a garment and they would clean it. Lesson #1 for software people: clearly there is a baseline level of comprehension somebody needs to embody to ensure the job gets done right the first time. “Is there anything you want us to pay specific attention to?” Something like that.
So now it’s come back next Tuesday. As predicted—can’t fault what is clearly a hedge to appear to underpromise/over-deliver—the text comes on Monday. (When I arrive, I see the original clerk, dealing with a well-to-do couple who also have a problem with their order.) When it’s my turn to pick up my coat, I see that the stain still isn’t completely out, and a piece of the coat—erstwhile taken off and safety-pinned to the hanger—is missing.
This is what got me thinking about the parallels to my line of work. When I showed up the first time, I was already enervated: I had a situation thrust upon me that I hadn’t anticipated, and wanted the matter dealt with as soon as possible. By the second time, I was annoyed, but controlling it. By the third time I truck out there, I’m in a worse position than when I started, anticipating at the very least that I’m going to have to come back a fourth time, and the response I get from the clerk, is lawyering:
“Some stains just don’t get out completely.” (me, sotto voce: yeah but it might have if you had done your job the first time and written a note like your colleague did instead of letting it sit like that for over a week.)
“The missing piece is probably at the plant; we can send it here tomorrow.” (me: probably? What happens if you can’t find it?)
“I don’t have the authority to promise you anything.” (me: I don’t care; tell me the name of somebody who does.)
“All the managers are gone for the day.” (me: Jesus fucking Christ.)
There was a video by Rory Sutherland (the wonderfully friendly ad-man from Ogilvy; I’ve interacted with him in the past) on Ole Peters’ ergodicity economics channel talking about why he was so interested in the subject. (Ergodicity in a physical system is when the time average is equal to the ensemble average, so you can calculate future outcomes without the expensive task of tracking the system’s individual elements.) He’s like, all these companies that target averages are missing the point: each customer has a memory of their experience interacting with you, and it compounds over time. Three bad experiences in a row is enough to not only turn somebody off you for good, but to actively go out into the world and speak ill of you, so as a business, you should be targeting that. My topical remark here is that if somebody shows up to your shop with a garment worth more than the rest of their wardrobe combined, that is effectively ruined save for your intervention, they are already on strike one. You have an opportunity here to be a hero, or you can make the situation worse.
Once my blood pressure finally returned to within a standard deviation of normal, I got to thinking about my first real job: tech support at a Web hosting company in the original dot-com era. What we were selling was the place to put your website (which itself was your own problem). You still, however, had to buy the name for it separately, from the monopoly known as NetSol, which was something we would broker. At the time, a domain name was an expensive and characteristically non-refundable purchase—in nominal terms, about ten times the monetary commitment it is today. (An SSL certificate, needed for e-commmerce—and which now typically costs nothing—was an even more expensive non-refundable outlay.) Several times a week (a day?), somebody would plug in their credit card looking to cash in on the internet gold rush without understanding one jot about what it was they were paying for, promptly change their minds, and demand their money back. Then the poor schmucks a few desks over in customer service had to calmly explain why this was impossible, because we didn’t have their money: at least one, if not two other entities did, and they had neither the interest nor the obligation to give it back.
I don’t think we were even marking these products up significantly, if at all. In retrospect, it would have been smart to do so, if for no other reason than as insurance to paper over what it cost to refund the people who wanted one—or at least sell the option as an add-on. That said, the secondary market in disused domain names didn’t exist yet, and as mentioned, at the time they cost 10X what they do now. So who knows, maybe the numbers would never have worked out.
This problem is pervasive in any commercial risk around computers—and especially when you involve the internet—because in a network of peers, no single entity, whether human or corporation, is accountable for your entire experience. If you buy a Windows computer, the hardware is guaranteed to the extent that it runs Windows. Windows, on the other hand, doesn’t guarantee anything. If you spend more and buy a Mac, you have a de facto✱ guarantee that you can get as far as running apps and looking at websites, and that the product won’t spontaneously torch all your stuff, but nothing beyond that.
✱ I say de facto here because Apple also disclaims any kind of warranty on its software—without which the hardware it sells is sharply depreciated, if not completely worthless. But if it wasn’t sufficiently reliable in the wild, nobody would ever buy their products. Understanding who’s actually responsible for any one particular aspect of a computer-mediated transaction or other is a perennial problem. (Do you remember the days before the iPhone, when people associated their cell phone handsets with the network and not the hardware manufacturer?)
And then there’s Linux, for which the only truly accountable actor in the system is you. And it shows! The experience of using Linux is an endless parade of “not my department”, because everybody contributing their part is doing so on their own time, for free. So it isn’t any one person’s department, even when some company or other makes its best effort to shrinkwrap it.
This actually reminds me of some of the critiques of Mastodon as a replacement for Twitter: you can’t even compare them because Twitter is a distinct legal entity while Mastodon is a protocol implementation that anybody can run. There’s no single point of accountability by design.
When you run a service that involves taking custody of somebody else’s property, you’re effectively on the hook to replace that property if you can’t get it back to them in one piece. (Of course, you could disclaim that, but you probably won’t get much business.) This is a risk you can actually write up actuarial tables for, and price into your service. With software, however, it’s possible—although importantly not always—to destroy so much more value in an engagement than you could ever gain from any number of successful sales, so you preemptively disclaim all liability. This is not only because of damage you can potentially cause, but also, almost none of your inputs can promise you a warranty, because they’re in the same position. If you had to absorb that risk, and pass the cost of circumscribing it onto your customers, you wouldn’t find anybody rich enough to pay the bill.
Obviously I know E&O insurance is a thing, but it is super clunky. The cost of underwriting it—and thus the cost of the premium—is so big as to make it unworkable for anything but projects that are already big and expensive. Big firms say they won’t do business without this many dollars in E&O coverage, irrespective of the actual risk profile of the project, which could be nothing, or far more than any reasonable insurance would ever cover. It also potentially creates a perverse incentive—not unlike life insurance—that a given project is more valuable dead than alive.
I guess the moral of the story is, if you can’t earn a profit while absorbing certain losses that are statistically bound to happen over the ordinary course of doing business, the ethical course of action is to be forthcoming with your customers/clients about the risks they are necessarily assuming when dealing with you. To use the dry cleaner as an analogue, they will assume the risk of losing or damaging my property (again, actuarial tables), but cleaning the garment—the actual service—is a “best-effort” proposition. (After two weeks and four trips and an 80% removed sour cream stain, I give that part of the experience a B-minus. The management was likewise professional about it.) We in software have a problem with this because, I argue, we have poor proprioception when it comes to the kinds of snags we can smooth over for customers, versus the kinds of risks we just can’t afford to take on.
I think part of it has to do with the fact that making software is just really hard. In a sufficiently tightly-coupled system, none of it works until all of it does, and just getting the damn thing to work at all will suck up as much energy as you allow. We should be keeping some (arguably up to, or perhaps more than half) in reserve for managing our relationships with customers. This would require a radical reorientation in approach. It means progress will be slower—but how much slower is it, really, if you don’t have to re-do the work? It means new tools for communicating progress, especially when that progress inherently does not manifest as “shipped features”. The fundamental deal around software has been a central part of my work for some time—that is, precisely what you promise your customers, and how you communicate what you can and can’t do for them. This is going to be an increasing focus in 2023.
So what have I been working on?
In the last couple months, a bunch of stuff has started to coalesce together. For one, the first serious work on the IBIS tool in nine years, which provides the infrastructural basis for the value-based development methodology and crucible for the specificity gradient. Much like Mastodon, actually, this system can be viewed as an orchestration around a set of open data vocabularies, designed to interact with—and ultimately outlast—any one piece of software.
Another thing I’m doing is doubling down on what I’m calling dense hypermedia. In short, it’s the opposite of what you just read: tiny texts (and audiovisual content!) with an explosive quantity of links betwixt. Part of what’s kept my head down for the last several weeks is that I tried to make some for somebody and stepped on every conceivable rake in the process. On the plus side, I’m mostly out of rakes. Once I push that out the door, I’m going to take the next couple weeks to finish the refactor of the Content Swiss-Army Knife (that I started around this time last year) that will organize its code well enough to be appropriated as the backbone of a replacement for the sclerotic and unworkable IBIS tool prototype; something that I will ultimately, in 2023 inshallah, turn into a product.
Another thing I’m thinking about a lot, in the wake of Twitter’s slow-motion implosion, is doing something…community-ey. I’m not really sure what it’s going to look like yet but I already have most of the ingredients:
a content management system (once I finish said overhaul)
the all-important payment processor, for Premium Content™.
I’m also mulling an all-access pass for existing Nature of Software subscribers. The big question for the moment, though, is all access to what?
The role Twitter played for me that I’d really like to replicate, is a stream of contemporaneous links, discussion around said links, and shitposting. It was sort of a human-powered replacement for RSS (and I’ve remarked that it’s been trailing off in that capacity long before The Muskening®), IRC, and blog comments.
Indeed, the short-lived and extremely poorly-considered initiative to ban certain links—and the highly-predictable revolt that ensued—demonstrates just how essential to Twitter linking really is.
I’m not interested in creating yet another social media site or even a Web forum, per se. I’m actually not interested in places to hang out and talk about what’s going on right now—there are plenty of places for that already. Where I think I’m going with this is something much more like an archive, that’s there when you need it, for ideas that accumulate over time. I want to start by distilling a lot of my writing into the essential ideas so you don’t need to read half a million words to understand them. I also want to turn out some structured data products, like concept schemes and annotated references. This fediverse business is also very much aligned with my values. I wonder if I can put these together somehow.
Anyway, back to finishing Chapter 5. Hopefully I can get it out just in time for Christmas, if I don’t spend too much time shitposting on Mastodon. If you aren’t already a subscriber to The Nature of Software, I entreat you to check it out.
Thanks for reading The Making of Making Sense. Subscribe for free to receive new posts.