Code and Data: A Fundamental Duality

The boundary between code and data is far more porous than commonly thought.

A program source, after parsing, is merely an abstract syntax tree: a data structure like any other, with nodes, branches, and leaves.

Lisp made this equivalence explicit from its origins: code is a list, lists are data, and eval transforms data into executable behavior. Macros, metaprograms, compilers: all manipulate code as data that can be inspected, transformed, and generated.

Conversely, sufficiently expressive configuration data (business rules in JSON, workflows in YAML) becomes disguised code, interpreted by a runtime that gives it meaning.

Duplication as Debt

This equivalence has a direct consequence on duplication.

Data duplicated in two places will inevitably diverge: someone will update one occurrence while forgetting the other, and inconsistency will silently take hold. This is why normalized databases avoid redundancy: a single source of truth, with references to that source.

Code, being data, obeys the same law. Duplicated code will eventually diverge: a developer will fix a bug in one copy without knowing the other exists, or will evolve a behavior here but not there.

Duplication is debt that accrues interest. A pricing rule duplicated in four places and modified in only three: that’s a customer receiving an inconsistent invoice, a commercial dispute, a loss of trust. These divergences propagate silently until they become visible incidents.

Coincidence vs Shared Behavior

The reflex to systematically consolidate all similar code is a mistake. Two identical code fragments today won’t necessarily need to have the same behavior tomorrow: they may only be an accidental coincidence, valid today only.

The question to ask is therefore not “do these two pieces look alike?” but “must these two pieces evolve together?”.

• If modifying one must always entail the same modification to the other, then they represent a single behavior and deserve a single implementation
• If one could legitimately evolve independently of the other, merging them would create artificial and harmful coupling

Consistency Over Time

The underlying imperative is therefore behavioral consistency over time, not syntactic resemblance in the moment.

Two distinct modules that calculate a 20% VAT should not share this code if one concerns France and the other a country whose rate could change independently.

Conversely, two apparently different calculations that must always produce the same result (a displayed price and an invoiced price, for example) should share their implementation even if their calling contexts differ.

Deliberate duplication and deliberate consolidation are both design choices; only accidental duplication is a fault.

In regulatory contexts, this distinction becomes critical. An auditor asking “where is the source of truth for the processing fee calculation?” expects a precise answer, not “in several files we keep manually synchronized.” Duplicating business knowledge turns every audit into code archaeology.

DRY Properly Understood

This reflection connects to the DRY  principle (Don’t Repeat Yourself) often - mistakenly - understood as meaning “never write the same thing twice.”

Hunt and Thomas’s original formulation is more subtle:

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

— Andy Hunt & Dave Thomas, The Pragmatic Programmer (1999)

It’s knowledge that must not be duplicated, not text. Two identical lines may represent two distinct pieces of knowledge; a single piece of knowledge may express itself differently depending on context.

Seeing code as data, that is, a structured representation of behaviors, reminds us that the question is never syntactic but semantic: what behavior does this code encode, and is that behavior one or multiple?