Counting the Arrows: What Britain's Military Supply Chains Reveal About Modern Dependency Management

In the fourteenth century, the Office of Ordnance maintained detailed records of every bow, arrow, and siege engine held across England's garrison network. These were not merely administrative documents; they were operational instruments. A constable who could not account for the materiel under his charge was not simply disorganised — he was a liability. Campaigns failed not because armies lacked courage but because the arrows ran out, the bowstrings rotted in the damp, or the replacement parts for a siege engine arrived in a configuration incompatible with the machine already in the field.

The engineers responsible for modern software infrastructure will recognise this failure mode immediately. The specific objects have changed — container images rather than crossbow bolts, package registries rather than castle armouries — but the underlying problem is structurally identical. Distributed systems fail at the seams where components meet, and those seams are defined by the quality of the logistics that connect them.

The Armoury as Registry

The Tower of London served, from the thirteenth century onwards, as the central armoury for the English Crown. Its function was not merely storage but standardisation. Equipment held at the Tower was inspected, catalogued, and maintained to a consistent specification. When materiel was distributed to outlying garrisons, the Tower's records provided the authoritative reference point for what had been issued, in what condition, and to whom.

This is, in operational terms, a remarkably accurate description of a modern container registry. The registry serves as the canonical source of truth for the software artefacts that a distributed system depends upon. Images are versioned, catalogued, and — in well-run operations — scanned for vulnerabilities before distribution. Downstream services pull from this central store with the expectation that what they receive meets a known specification.

The Tower's model also highlights the importance of provenance. Medieval armourers were meticulous about recording the origin of materials and the identity of craftsmen responsible for specific items, partly for quality assurance and partly to establish accountability when things went wrong. Modern container security practices — image signing, supply chain attestation, software bill of materials — are solving the same problem. When a vulnerability is discovered in a widely-deployed image, the ability to trace every instance back to its origin, and to understand what depends on it, is precisely the capability that determines whether the response is orderly or chaotic.

The Garrison Problem and Configuration Drift

Maintaining standardisation across a distributed network of garrisons was one of the enduring challenges of medieval military logistics. Equipment issued from the central armoury would, over time, be modified locally — repaired with available materials, adapted to local conditions, supplemented with items sourced independently. Each individual modification was often reasonable in its immediate context. The cumulative effect was a network of garrisons whose actual inventories bore an increasingly uncertain relationship to the central records.

This is configuration drift, described in the language of the fourteenth century. The phenomenon is so familiar to infrastructure engineers that it has become something of a professional cliché, yet it remains one of the most persistent sources of production incidents. A server that was provisioned from a standard image six months ago has, through a series of individually reasonable interventions — a hotfix here, a manually installed dependency there, a configuration value adjusted during an incident — become something meaningfully different from that original specification. When it fails, or when a colleague attempts to reproduce its environment, the divergence reveals itself at the worst possible moment.

The medieval military's response to this problem was periodic muster — a formal inspection process in which garrison inventories were audited against central records and discrepancies were documented and resolved. The muster was not a pleasant event for constables who had allowed their inventories to drift; it was, however, an essential mechanism for maintaining operational coherence across a geographically dispersed force.

Infrastructure-as-code, when practised with genuine discipline, is the contemporary equivalent of the muster. Treating infrastructure configuration as a versioned, auditable artefact — and enforcing that configuration through automated mechanisms rather than human compliance — prevents drift at the point of origin rather than detecting it retrospectively. Organisations that have made this transition consistently report fewer incidents attributable to environmental inconsistency. Those that maintain large fleets of manually configured systems are, in effect, running a garrison network without a muster schedule.

Dependency Chains and the Failure of Single Points

The logistics of a medieval campaign involved supply chains of considerable complexity. Grain, timber, horses, iron, and manufactured goods moved along routes that were vulnerable to weather, brigandry, and enemy interdiction. Military planners who failed to account for the fragility of these chains — who assumed that supplies would arrive because they had been ordered — discovered the consequences in the field.

The Battle of Crécy in 1346 is often cited as a demonstration of English archery's superiority. Less frequently noted is the logistical achievement that made it possible: the systematic pre-positioning of arrow supplies along the campaign route, managed by an Office of Ordnance that understood its supply chains well enough to anticipate failure points. The archers did not run out of arrows because someone had done the dependency analysis.

Modern software systems are similarly dependent on supply chains whose fragility is easy to underestimate in normal operating conditions. The incident in 2016 involving the removal of a small JavaScript package from npm — which cascaded into build failures across thousands of projects — was a supply chain failure of exactly the medieval type. A single node in a distributed dependency graph was removed, and the systems that depended on it, often without their owners' full awareness, failed in sequence.

Dependency management practices that treat the supply chain as a potential failure surface — pinning versions, mirroring critical dependencies, auditing the transitive dependency graph — are applying the same logic that the Office of Ordnance applied to arrow stocks. The goal is not to eliminate dependency on external supply but to understand that dependency well enough to manage its failure gracefully.

Standardisation as a Force Multiplier

One of the most consequential decisions in English military logistics was the standardisation of the longbow draw weight and arrow specification during the Hundred Years War. By ensuring that arrows produced in different locations were interchangeable, the Crown dramatically simplified its supply chain. A garrison that exhausted its local stock could be resupplied from any other source in the network without compatibility concerns.

The parallel in software engineering is the value of genuine interface standardisation. Microservices that communicate through well-defined, consistently implemented contracts can be independently deployed, scaled, and replaced. Teams that have invested in this kind of standardisation find that operational incidents are more contained — a failure in one service does not propagate unpredictably through the system — and that the cognitive load of maintaining the overall system is substantially reduced.

Conversely, systems in which each service has evolved its own idiosyncratic communication patterns, its own configuration conventions, and its own deployment requirements are the software equivalent of a garrison network in which every castle uses different arrow specifications. The individual components may function adequately in isolation. The system as a whole is brittle, expensive to maintain, and deeply resistant to change.

The Ledger as Living Document

What the medieval Ordnance Office understood, and what its most successful practitioners demonstrated, was that the logistics ledger was not a historical record but an operational instrument. It was useful only insofar as it accurately reflected the current state of the supply chain, and it required continuous maintenance to remain so.

Engineering teams that treat their dependency manifests, infrastructure definitions, and configuration records as living operational documents — updated continuously, audited regularly, and treated as authoritative — are applying this principle directly. Those that allow these records to drift from reality, or that maintain them only for compliance purposes rather than operational ones, are managing a garrison network by guesswork.

The arrows still need counting. The methods have changed considerably since the fourteenth century. The requirement has not.