Relative, Not Deterministic — On an Attitude Toward Tools and Methods

The articles on this site cover, on the surface, a scattered set of topics: keystone correction of slide photographs, route planning for cycling, the two-layer architecture of a sensor logger, the standardization of meeting records, a remote LuaTeX execution environment, the principle of not writing code yourself — design decisions about tools and workflows, articulated for each domain in turn.

But these articles share an unstated premise: an attitude of not fixing tools and methods as “the correct procedure.” This piece pulls that premise out and articulates it. Keep it as a horizon for reading the rest, and as a statement of what this site is doing.

From the experience of “best practices” going stale

If you work long enough in engineering, you watch the things that were once called “the definitive version,” “best practice,” “the right answer” go stale within a few years.

The reason is simple: the environment moves. Requirements change, constraints change, toolchains change, team composition changes, the scale of the data changes. Freeze a procedure and what’s left is a fossil optimized only for the environment at the moment of freezing. The fossil becomes brittle the instant the environment moves.

So holding “the correct procedure” is itself a trap. What you should hold instead is an attitude of re-confirming meaning as the situation requires — and this is not resignation or relativism. Quite the opposite: if you want to remain robust while the environment moves, you have no choice but to put your center of gravity on a movable attitude rather than a fixed procedure. That is an engineering conclusion.

This site supports that attitude with three notions: mediation, différance, and the asymmetry of V&V. Each receives a more rigorous treatment elsewhere¹; here I explain them operationally, in shop-floor language.

Mediation — tools are not neutral

A tool stands between a purpose and the work. And the mediating thing that stands in between is not transparent. What can be seen, what can be done, what becomes easy to think — the mediator itself prescribes these.

Concretely:

• The moment you adopt git for version control, you start thinking of development in units of “commit,” “branch,” “history.” git subtree split becomes available as a natural operation, while history management at some other granularity drops out of awareness.
• Choose a programming language and you are pulled toward the solutions that language makes feel “natural.” A language where list comprehensions are ordinary and one without them lead the writer to different ideas for the same problem.
• Choose the Geospatial Information Authority of Japan’s 5 m mesh DEM for elevation data and the problem “anomalous elevation over bridges and tunnels” comes into view; choose 30 m resolution data and that problem never enters the field of vision at all.

So choosing a tool is not only a question of “efficiency” but a question of “the shape of thought.” That is why the articles here re-ask, every time a tool is adopted, “why this tool?” The single responsibility discussed in Separating Tools from Orchestrators is, from this angle, “deliberately narrowing the range a tool mediates” — narrow the range and you can predict the “shape of thought” that tool prescribes, and substitution becomes feasible. The don’t-write design of Great Programmers Use the Code of Excellent Programmers is likewise a choice of mediation: entrusting the “shape of thought” of the parts you don’t write to other people’s excellent implementations.

The wariness about a mediator being placed outside your own control — the design that pays no platform tax discussed in Designing Time-Resilient Assets, choosing free, long-stable open formats and open source — also follows from being conscious of mediation. When a mediator changes at someone else’s convenience, the premises of your own thought change at someone else’s convenience.

Différance — meaning emerges retroactively and relatively

When you begin a design, “what you want to do” is not fixed from the start. Even when you think it is, it changes as you build.

The four-step procedure referred to several times on this site — “clarify what you want to realize → survey existing code → design the orchestration → implement the missing tools” — looks at first like a linear process flowing top to bottom, but it is in fact a cyclic structure. Surveying existing code raises the resolution of “what you want to realize”; designing the orchestration changes its contour; implementing the tools redefines it. The purpose is articulated retroactively — the purpose you set at the start is only a provisional placeholder.

Concretely: while building the route-planner discussed in Knowing a Cycling Route in Advance, the initial purpose was the vague “I want a route-planning tool.” Implementing the segment-selection UI, the gradient colormap, the bridge-and-tunnel correction — through that process it became articulated that “what I actually wanted was to accurately grasp, before riding, the total distance and the total gradient” — a sentence I could not have written before building it.

Design is not “implementing a correct answer fixed in advance” but doing it and re-confirming the meaning. That is why the articles here do not write design decisions as “this was the correct answer.” They write “this judgment was made, for this reason.” The judgment is relative to the environment; in a different environment, a different judgment is correct — that structure is left in place.

This attitude of “re-confirming meaning relatively” also shows up in the relations between articles. The articles on this site are not fixed inside an absolute taxonomy; they are tied to each other by relative relations — “this is more concrete than that one,” “this applies the principle of that one to this domain,” “these two are side-by-side case studies.” An article’s meaning changes depending on which article you place beside it.

The V&V asymmetry — verification and validation are different activities

Software engineering distinguishes Verification from Validation. The two are structurally asymmetric.

• Verification is detecting the difference between two adjacent stages. Specification and implementation, design and test, requirements and specification — it checks whether neighboring stages agree. This is close to mechanical and lends itself to automation.
• Validation is different. It is “articulating the purpose itself retroactively” — the act of discovering “what was it that we wanted in the first place.” This is not confirmation (“checking whether it meets the purpose”) but discovery (“finding out what the purpose was”).

In an engineer’s daily life: the tests all pass (Verification has succeeded), but you pause and ask, “Is this really what I wanted?” — that question is Validation. And in many cases, in the process of answering it, the purpose itself gets rewritten.

Conflate the two and you fall into the trap of “if the tests pass, it’s done.” The respect for inter-stage interfaces discussed in Standardizing Records (not inventing a standard but connecting via existing ones like GPX / KML / JSON) is the work of arranging the object of Verification — making it easy to check that neighboring stages agree. The judgment “choose a format you can re-analyze ten years later” discussed in Designing Time-Resilient Assets is, on the other hand, the work of securing the site of Validation — leaving room for the you-of-ten-years-later to articulate retroactively “what it was that I wanted to record.”

Treating difference-detection (V) and the retroactive discovery of purpose (Validation) as different activities. This too is part of “relative, not deterministic.” Since Validation can rewrite the purpose, the purpose you set at the start cannot be treated as absolute.

What this looks like when dlab puts it into practice

Mediation, différance, the V&V asymmetry — drop these three into tool design, navigation, and the way articles are written, and the site’s concrete choices fall out.

Tool design. A tool is not “the answer” but “something that stands in between,” so it is closed to a single responsibility and made substitutable. Make the range it mediates explicit and you can predict the “shape of thought” that tool prescribes, and a swap becomes feasible when the situation changes. Correcting the Distortion of Slide Photographs and Knowing a Cycling Route in Advance — actually, see also Designing a Sensor Log — each articulates the judgment of closing functionality to a minimum.

Navigation. The inter-article links on this site are not a fixed tree of upper/lower but a field of relative relations. “More abstract / more concrete,” “above / below,” “lateral” carry meaning as relations between articles — this piece stands on the more abstract side, the case-study cluster on the more concrete side, but even this above/below is not absolute, and the meaning changes depending on which article a reader enters from.

The way articles are written. Rather than presenting “the correct procedure,” they articulate “this judgment was made, and why.” The reader is not meant to copy the procedure but to transfer the pattern of judgment to a different problem. Tracing not “how to use Canny edge detection” but “why the judgment of attempting automatic detection while leaving room for manual fine-tuning was taken” — the latter is what carries over when you face a different problem in a different domain.

A V&V attitude. The site itself articulates retroactively what counts as a “useful article.” This piece, too, was a placeholder (“an article tidying up the premises of the methodology”) before it was written; having written it, it is articulated as “the article that declares the horizon running through every article on the site” — a sentence I could not have written before writing it.

A declaration of horizon

The rigorous formalization of mediation, différance, and the V&V asymmetry — their formal definitions, the connection to a generalization of the OODA loop, the justification for choosing a discrete formulation — is done elsewhere, not on this site¹. This site does not make that its subject. It gestures toward it as a horizon and remains a place for practical craft.

There is a line here, where “step in and it becomes the universal labor of knowledge.” Elementally reductive expression by symbols, and its Verification & Validation — that is the universal labor of knowledge itself. This site stays on the near side of that line, but it does not hide that the labor is in the background. Readers who want the theory go to the preprints in the footnote; readers who want the judgments of implementation go to the case-study cluster on this site — that is the division of labor.

Finally, the claim of this piece compressed into one sentence:

Not treating tools as “the correct procedure” — confirming meaning relatively, not deterministically, and responding flexibly to changes in the situation — this is the premise behind every design decision dealt with on this site.

When you read the articles that follow, recall this premise. None of them says “this is the correct answer.” Each says “this judgment was made, for this reason. If your situation differs, a different judgment is correct.”

References