No Stuck Boat Content, I Promise
My latest toy is coming along
A couple newsletters ago I wrote about how my brother is a full-time actor, and how he might audition up to fifteen times a month to land just one or two gigs, and he lives quite well off that. It’s a lot of hours to spend speculating with maybe a 10% chance of paying out, but what’s interesting is it does pay out on average, and the audition—the unit of speculation—has a pretty well-defined form factor. So I decided to model it.
This is one of the more sophisticated of what I’m calling toys for thinking, which I’ve been making here and there since about 2013. I draw my inspiration in part from Bret Victor, who makes way nicer toys than me (for now), and who astutely observed that arguments around, for instance, public policy, which almost always concern the allocation of finite resources—and thus some kind of quantitative model—pundits can argue whatever case they want, simply by choosing favourable parameters. He says the intellectually honest thing to do is to publish the model itself, and enable the reader not only to supply it with values of their own, but also move it around to see how the outcomes change under differing assumptions. He called this “model-driven debate”.
I am keenly interested in this rhetorical angle, but I am also invested in these models as tools for comprehension. Consider this particular model parametrizes the general problem of pitching, and the idea is to determine which combinations of pitch time/cost, to probability of success, to size and frequency of gig, are viable and which are not—because this is something I sure as heck can’t game out in my head.
The problem with these damn toys is they take daaaaaays to write, and most of the effort isn’t even on the actual thing, but some dumb ancillary housekeeping detail or other. (The rest is just hundreds or perhaps thousands of page refreshes, trying to get the behaviour right. Victor said the similarly-instrumented essay that contained his aforementioned remarks took two months.) So some of the days this last one took actually went toward encapsulating a lot of that housekeeping so hopefully the next one will only take mere hours to make.
Anyway, what you’re looking at is just the control panel, I have yet to make the actual model itself. Hopefully I’ll have that done by my next missive. If you’re lucky, you can probably catch me finish it off on Twitch.
Babytown Frolics
Ever since NFTs✱ became a thing, I have wanted to see one—like the actual literal data payload that gets saved out to the blockchain. I was too lazy to dig through the layers of interpretation so somebody beat me to it, and golly bob howdy what a gift that was.
✱ Non-Fungible Token for those of you not hip to the lingo: a kind of cryptographic sales receipt that you can buy with internet funny money (which you buy with ever-increasing quantities of ordinary money). It’s a tamper-proof way to assert that you own something (anything, theoretically) that lives out in public and is supposedly as durable as the distributed information system it’s running on top of. (The system itself is assumed to be durable because people are incentivized to keep it alive by way of it making them rich.)
It is also perhaps worth remarking that cryptographic certification technology has been around for decades; the thing that’s new is that the certificate now lives “out there” in the ether (ha) so you (theoretically) never have to worry about losing it.
(I am also bracketing any discussion of the environmental implications of NFTs or cryptocurrency in general, as the issue appears to be hairier than either side of that debate is willing to concede.)
It turns out that what is being signed and transacted (for truckloads of actual dollars) a lot of the time is actually just a link to a webpage on one of these sketchy fly-by-night intermediaries. This could be interpreted as shady and premeditated, but is more likely a rookie mistake. Others appear to have given some thought to a more durable and vendor-neutral way of addressing these objects, only to go and mess up the implementation. (An important detail about NFTs is that if you screw one up you can’t go back and fix it, which is why it is said that you “mint” them.)
So far NFTs are being used mainly to certify things that can be represented as a single data file. From what I understand (I’m learning), you could theoretically just shove the file you want to certify itself straight into the NFT, but that will be terrifically expensive. So you certify a reference to the file instead. The dumb thing to do here is to use a regular Web address, because those depend on things like specific legal entities remaining online and solvent and paying their internet bills on time. The smarter thing to do is to use a thing called IPFS (“Interplanetary” File System) which has its own addressing scheme which is not just a goddamn ordinary Web link to an IPFS gateway, you geniuses. However, IPFS is a live system that still depends on somebody out there caring enough about the file in question to keep it online in perpetuity.
Apparently some NFT referents are already disappearing from IPFS because nobody can be bothered to host them.
Okay, so I actually, like, know a little bit about content-addressable storage, having written two content-addressable object stores myself (well, really just the same one twice). And the reason why I wrote my own was so that I could organize around a specific interface that happens to be defined in a standard. So if I was designing an NFT payload, I would make it point to the file’s cryptographic fingerprint, which will look something like this:
ni:///sha-256;PX8QIDHjgx4FrH9xedC4Ifm80JsbUg7t-Fqm1oC9uVU
This will unambiguously identify the file that has been certified. It won’t locate the file, but you could presumably use any mechanism to do that, not just IPFS.
I was actually astonished to learn that IPFS addresses, while they are strictly speaking cryptographic identifiers, don’t actually identify the files themselves. Rather, they identify the first step of a path through a bunch of chunks of said file. This seems to me to be a bit of an oversight, but I thiiink it can be palliated? I’m not well-versed enough to judge.
Even my solution, though, is problematic. Here is an example: NFTs appear overwhelmingly to certify image files of one kind or another, and what you actually care about in an image file is the rectangle of pixels that constitute the image. However, an actual image file is much more than that. Not only is there the encoding/compression algorithm of the pixel data itself, but pretty much every algorithm has a bunch of tunable parameters that will produce a different file on disk. And then there’s typically a few flavours of embedded metadata, and then the fact that all of these things can be shuffled around arbitrarily in the file, and then there’s the fact that each particular implementation of each file format encoder is bound to have bugs and idiosyncrasies, or interpret the format specifications slightly differently. These details add up to basically being able to represent an exactly identical image (I’m not even gonna consider lossy compression here) as a zillion possible different representations when stored, each with its own distinct fingerprint.
So let’s say you lost access to the particular file that had been certified in the NFT, as well as the software that encoded that file. But, for some reason you have another identical copy in some different file format. It is entirely conceivable that you could be unable to recreate the exact file that produced the fingerprint in the certificate. If that’s the case, can the file that you do possess ever be considered an original?
I mean, the obvious thing would be to paint the image to a raw frame buffer and then fingerprint that, but that would be annoying because no image would ever actually be stored that way, so you’d never be able to locate it. I suppose you could put both fingerprints into the NFT though, one to facilitate lookups and another to verify the content free of file format baggage. The other obvious thing is to strip the “original” image file of all its metadata before certifying it, so there’s less to vary.
Anyway, that’s images solved I guess, now do the same thing for literally every other media type.
“Design” is now “Product”
Dan Zollman recently remarked on the inflation of the word “product” in design circles which is something I’ve been quietly monitoring for a while. A cynical take would go something like, as designers move up the corporate ladder they’re being given roles like product manager✱, which even though it has the word “manager” in it and comes with a staff and budget, absolutely is a design role. Those lower on the totem pole see this and ape it in a bid to gain more influence over strategy. I’m not trying to be glib here! The “seat at the table” trope has been a thing for-eeever in the design community. Arguably this is what “service design” was supposed to do ten years ago—try to break design out of its position as yet another technical functionary and into strategery.
✱ For those who again may not be familiar, a product manager is responsible for and holds residual control over the strategic decisions behind one or more particular commercial offerings within an organization, while a project manager marshals the people and the resources to get the job done. (Also worth remarking a project manager in the tech industry tends not to be nearly as powerful as one in say, construction.)
We’re a couple decades into business leaders learning that design is something they need to pay for, but the median business leader still doesn’t seem to understand precisely what “design” means or what role it plays in their organization. If this wasn’t the case, I don’t think we’d still be seeing as many “slashies”—that is the “UI/UX designer” job title—as we continue to see. I’ve been in meetings with these business guys; they say things like “look and feel” and “make it easy to use” and “user-friendly”. Their vocabulary hasn’t evolved past 1985—but like, why should it have? What conceptual framing have we provided them, and widely promulgated, other than “design means spending more money and taking longer to make your product maybe look nicer✱, where the bet is that enough additional people will buy it to pay for the overhead and then some”? In this sense I think I might actually be pro-“product” because it may just stand a chance of breaking through.
✱ I am less optimistic that the average business guy groks the difference between “looks nicer” and “works better”, mainly because designers often don’t get the power to make more than cosmetic changes, so business folk never get to experience the full power of what a bona fide designer can do for them. (Too many people have written about that phenomenon to count.)
My optimism can potentially be understood by interrogating what even is a product anyway. I’m gonna argue that a product is not an artifact as much as it is a set of boundaries around a social and/or economic relationship. A product is a manicured context, a front-loaded set of things you are—and are not—willing to promise somebody, so their entitlements aren’t ambiguous once they have paid you some money. What makes a product different from a service is that generally the relationship is biased toward people going their separate ways after the transaction is complete, which happens quite quickly, whereas a service often entails a protracted or ongoing use of your own resources as a service provider. My basis for this distinction is precisely the scenarios where “product” and “service” are harder to tease apart:
Product-as-a-service: Every SaaS company has to spend on an ongoing basis to stay online and be available 24/7, but everybody gets the same menu of features like it was an artifact in their own possession. (It just happens to change on them suddenly and without warning.)
Service-as-a-product: I noticed some time ago that banks frame their credit offerings as “products”, even though there are maybe two or three parameters involved in lending money, which is an ongoing relationship that typically lasts years. What makes it a “product” to them is the context around lending money to what kind of person, for what purpose, and on what terms.
Considering products strictly in terms of artifacts misses an opportunity to think about how the process of getting a system to function and into a state of internal consistency is a radically different modality than the process of reconciling that artifact with the rest of the world. The former is analytic and additive, defining simple parts and composing upward; the latter is synthetic and subtractive, defining boundaries. Bruce Sterling said in a keynote many years ago but I still reference entirely too frequently: “objects are print-outs of social relationships”.
So what you’re doing when you’re “doing product” is precisely defining the identity and contours of these promises, and that is something business leaders understand. This brings me to what the hell even is design, anyway? What follows is a hill I will die on:
Actual design has very little to do with what tools or methodologies you use, or what your job title is, or what you have a degree in, or even anything like “creativity”; design is about your relationship to constraints. Rather: to what extent are you defining constraints rather than just obeying them? Design is about taking a universe of possibilities and converging onto exactly one outcome. Being handed a set of constraints which you treat like immutable laws of physics (because many of them are) and solving within that envelope is what engineering is. To wit: what most designers are doing most of the time is actually a form of engineering, and engineers are always doing at least some design.
A: “How many designers does it take to screw in a light bulb?”
B: “Does it have to be a light bulb?”
A: “It depends!”
This is because genuine design—the power to define constraints—is a privileged political position within an organization, and not everybody can occupy it. In other words, the “seat at the table” comes first. Design is Steve Jobs infamously dropping an iPod prototype into his fish tank, pointing at the bubbles coming out and yelling at his staff to make it thinner. It doesn’t matter what your title is; Jobs is the designer in that scenario. Obviously you do what he says or you’re fired.
To circle this back to “product” as the defining of constraints on a relationship, I want to consider the trope of logo designers offering their clients “options”, which cedes the role of the designer back to the client and invariably sets off another round of revisions. As object lesson we’ll take the very same Steve Jobs when he asked this of Paul Rand, whom he commissioned to do the logo for NeXT. Rand’s reply:
“No. I will solve your problem for you, and you will pay me. You don’t have to use the solution; if you want options, go talk to other people. But I’ll solve your problem for you the best way I know how, and you use it or not, that’s up to you—you’re the client—but you pay me.”
I cannot proceed without noting that the guy who shot this interview went on to spearhead the Juicero; it’s just too good a factoid not to mention.
This take-it-or-leave-it approach may have worked for the legendary Paul Rand (Steve Jobs took it after all), so your mileage may vary. The point is you have a lot of latitude to define the contours of your economic relationships before you get into them, and a lot less once you’re committed.