Le secrétaire de Fernand

Series

Encode the System

An arc moving from manifesto toward conclusion: programming is not merely writing code, it is encoding guarantees into systems.

3 of 7 articles available

The series

Article 1

Build Systems, Don't Polish Prose

We still talk about code as if it were style. But code runs in the world.

Article 2

Encode, Don't Imply

Why the implicit becomes fragile when humans and agents co-produce code.

Article 3

Make Feedback Loops Attribute, Don't Just Detect

Why feedback loops become more powerful when code makes its system concepts explicit.

Article 4Next article

Enforce Architecture, Don't Trust Intent

Why load-bearing architecture rules must become executable checks rather than trusted intent.

Article 5Coming soon

Build Guarantees, Don't Chase Bugs

Why the goal is not fixing bugs faster but encoding guarantees that make whole classes of bugs impossible, rare, or visible.

Article 6Coming soon

Structure Domain, Don't Scatter Rules

Why domain invariants belong in domain structures, not in rules scattered across code paths.

Article 7Coming soon

Encode Guarantees, Don't Just Write Code

Programming is the art of deciding which truths to make unbreakable, where, and at what cost.

Series glossary

Forty concepts used across the published essays. Each definition describes what the term means inside this series.

Abstraction

A representation that hides some details so attention can remain on the concepts that matter.

Central in article 2
Adapter

A thin layer translating between an external technology and the model or contract used by the system.

Architectural fitness function

An automated check that continuously evaluates whether a system still satisfies an architectural property.

Attribution

Identifying which rule, state, boundary, or responsibility produced the problem.

Authority

The part of the system allowed to decide or perform an operation.

Black-box test

A test that verifies observable behavior without depending on internal implementation details.

Boundary

A point separating zones with different responsibilities, levels of trust, or kinds of behavior.

Cognitive portability

The ability to recognize the same conceptual structure across different languages, frameworks, or implementations.

Central in article 2
Colocation

Placing related pieces of code near one another, even when they belong to different runtime or architectural zones.

Central in article 2
Contract

An explicit statement of what may enter or leave a boundary and what each side guarantees.

Correlation ID

An identifier used to connect logs, events, and calls belonging to the same operation.

Detection

Establishing that something is wrong.

Deterministic transformation

A transformation that always produces the same result from the same explicit inputs.

Discriminated union

A type representing a finite set of alternatives, each identified by a common distinguishing field.

Disposition matrix

A complete table classifying the meaning of every event in every possible state.

Domain event

A named record that something meaningful happened in the domain or system model.

Drift

The gradual divergence of code or behavior from the structure the system was intended to preserve.

Exhaustiveness

A guarantee that every possible case has been considered and handled.

Explicit

A concept represented in a visible, named, and inspectable form.

Explicit state

A named situation the system can occupy, represented directly rather than inferred from scattered conditions.

Feedback loop

A mechanism that observes the result of a change and returns information that guides the next correction.

Idempotency

The property that repeating the same operation does not produce additional unintended effects.

Implicit

Information required to understand the system but not directly represented in the code being read.

Invariant

A condition that must remain true throughout the relevant life of the system.

Example: A paid order cannot return to the pending-payment state.

Invisible dependency

Knowledge on which the code depends even though that dependency is not represented or enforced.

Central in article 2
Local feedback

Fast checks concerned with the code immediately being changed, such as types, compilation, and nearby tests.

Observability

The ability to reconstruct what a running system did, in which context, and why.

Probabilistic machine

A system that generates likely outputs rather than following one uniquely determined continuation.

Central in article 2
Production-like feedback

Checks of critical behavior under conditions resembling real execution.

Property-based testing

A testing approach that verifies general properties across many automatically generated inputs instead of relying only on manually selected examples.

Pure function

A function whose result depends only on its inputs and which does not modify external state.

Responsibility

The part of the system responsible for ensuring that an operation is accomplished.

Robustness

The capacity of a system to remain understandable, withstand deviations, and reveal what happens when it runs.

Side effect

An interaction with something outside a local computation, such as a database, network, file, clock, or device.

Snapshot

An immutable representation of the system state at a particular moment.

Central in article 2
State machine

A model that names possible states, accepted events, and allowed transitions between them.

Structural feedback

Checks that verify whether architectural boundaries, dependencies, and responsibilities still hold.

Trace

A connected record of the steps taken by an operation across the system.

Verification surface

The explicit forms in a system that tools and reviewers can inspect and check.

ViewModel

A representation prepared for a user interface that exposes the state and actions the view needs without embedding domain behavior in the view.

Central in article 2