(2022-09-10) Taylor The Specificity Gradient

Dorian Taylor: The Specificity Gradient. The specificity gradient is a term I came up with for a principle that I have held for many years now, that software is, as I said on a podcast back in 2010, a very verbose, very precise incantation specifying how an information system ought to behave. What gets written down as software code is the result of a long chain of deliberation, passing through the hands of numerous stakeholders from sharply different disciplines

Code has far too much detail, and is much too preoccupied with its own affairs, to be the authoritative place where business decisions are made

As a conceptual framework, the specificity gradient rests on the shearing layer or pace layer concept, which has had some currency in the design community for quite some time.

you build within the respective layers, not across them.

The idea of the specificity gradient is to create an unbroken line from the chunkiest thoughts to the most precise ones, adding detail every step of the way.

making decisions at the coarsest possible level, so they don't have to be relitigated over and over again in finer detail

coarser-grained elements tend to also be much slower-moving than the finer-grained ones

For software, a reasonable specificity gradient looks like this:

Business Ecosystem

Its purpose is to model how the organization interfaces with the outside world.

Embedded within this ecosystem—indeed, representable by the differences between current and future states of the ecosystem itself—are the organization's goals.

User Goals

Every product, software or otherwise, is going to have at least one archetypal user. It is important to recognize that a user may or may not be the same as the customer, but a user nevertheless has goals, and the purpose of the product is to help them achieve those goals, to the extent that they intersect with the business's goals (persona)

We see here our first jump up in specificity, and down in temporality: a user only (nominally) exists in the context of a product, and so will change as the product changes.

User Tasks

A task is a concrete thing that a user has to do to achieve their goal (job to be done)

we kind of need to gear down at this level, temporally speaking, since a user is potentially able to complete a task using more than one, or combination of, specific methods. So we need to capture the abstract task, as well as the concrete steps in each medium or channel

System Tasks

A system task is the sequence of concrete steps the system has to take to support the user in carrying out their task

System Behaviours

System behaviours are detailed, concrete, prescriptions and proscriptions about what the system must or must not do in the course of carrying out its tasks

This category is unusual to the extent that it has potentially the widest gamut in temporal sensitivity, eventually spanning several orders of magnitude. However the content is always going to take the form MUST or MUST NOT

Code

Code, of course, to the extent that it is getting any attention at all, is continually undergoing changes

In fact, I'm inclined to say that code is old, it's likely pathological: it exhibits unspecified behaviour, i.e., it does things and nobody knows how, or often even precisely what, so they're afraid to touch it, because the business depends on it. Part of the idea behind the specificity gradient is to prevent getting into this position.

Remarks About Code

Here is where I say something mildly controversial: I think way too much value is placed on code.

what seems to happen so often is that all the materials that served as the basis for all the decisions that made the product possible, are left to rot. This, I believe, is a mistake.

The code, on the other hand, is elevated to sacrosanct

If we treated code as what it is, namely, the substance at the very end of a long, multi-layered gradient of increasing specificity, then I don't think we would need to be so precious about it.

There Is Plenty of Precedent

programmers themselves already have pieces of this puzzle: behaviour-driven development, literate programming, design patterns, even plain-old bug reporting.

The military strategy, management strategy, operations research, and systems people have models out the yin-yang, and let's not forget the UX people, who fill in the rest. What's missing is an unbroken path that takes you from one end of the edifice to the other.

This Is a Structure, Not a Procedure

How I Ultimately See This Play Out

solvent of documents and data sources. Its job would be to make everything maximally addressable: jack into every API, decompose every document, suffuse every database.

This website would not have pages per se; rather everything navigable—that is to say, everything—would be a piece of structured data that could be transformed and composed into more complex structures

Well over a decade ago, we had these things called [[structured wiki]s, which is about as close to what I'm suggesting as one has ever gotten

even Roam lacks the structure I'd be looking for.

It is a safe bet that the overwhelming majority of this forensic content—to the extent that it exists—is going to (at least initially) come from conventional office file formats

Eventually, documents in general will recede in importance as origins of information and will instead become targets for projecting information. The native form of the content will eventually make its way toward the shape of a dense hypermedia network: small pieces, loosely joined.

In the interim I am confident that the spirit of the specificity gradient can be applied to existing tooling, assuming a modicum of discipline.