Boring technology is technology whose capabilities and failure modes are understood in the organisation that has to run it. The word is shorthand for supportable, not for old, and the argument’s originator is explicit that familiar technology can still be bad.
Familiar to the receiving team
The choice is made from the operator’s position, not the builder’s. A stack the delivery team knows intimately and the recipient has never run is novel technology at the point of handover, and the novelty arrives exactly when the people who understood it leave.
The published argument weighs organisation-wide operational and cognitive cost rather than a tool’s local suitability, and it permits new technology after three questions: whether the existing stack can solve the problem, why it is insufficient, and how overlapping tools would be migrated. The familiar three-innovation-tokens device is an approximate way of putting this, not an established limit.
So the worksheet compares the existing stack, the proposed addition, and a simpler alternative against the same actual task, recording the receiving team’s skills, deployment and recovery procedure, supplier dependence, current support status, expected maintenance, and exit work. Measured results stay separate from estimates, and empty cells do not become favourable scores.
A vendor proposing a graph database for a small internal directory is answerable by testing whether the existing database handles the specified relationships and queries. If it does, the addition needs another justification. If it genuinely fails a requirement the graph option meets, novelty alone does not settle the choice against it.
Portability is a claim about a task
Portability is the ability to perform named development and operating tasks in a specified receiving environment. It is bounded by task and environment rather than being a property of a framework.
Four things are separately demonstrable and get treated as one: source export, build success, runtime operation, and future modification. Declaring dependencies explicitly and isolating execution — including required system tools rather than assuming they are installed — is necessary and does not establish portability across every environment.
The distinction that catches transfers is between tooling needed to generate the first scaffold and tooling needed for later builds, changes, or operation. A recipient who can build an exported application, and cannot add a new form because that requires the supplier’s private schema generator, has proven the build claim for existing source and nothing about the maintenance workflow.
The exercise that settles it is a recipient operator performing a clean checkout, dependency acquisition, build, deployment, and one representative change in the agreed environment, with commands, versions, elapsed effort, and every supplier intervention recorded. Failed attempts are retained as evidence. A successful run supports the tested version, access, and environment.
Where a private tool is unavailable, it needs a disposition: obtain rights and access, deliver a maintained replacement, change the workflow, or narrow the transfer promise. Owning the generated source does not answer the permission question for the generator.
Lock-in is a trade with an evidence requirement
Dependence on supplier-controlled tools, services, or assets limits the recipient’s practical ability to operate, rebuild, change, or exit. Proprietary licensing does not establish an unacceptable dependency, and the same difficulties arise with open-source and internal components.
Commercial lock-in and technical lock-in are distinct, and switching cost and portability are weighed against the value of the current service rather than minimised on principle. Supporting glue code is a documented source of dependence on a package’s peculiarities, including the cost of testing alternatives.
The diagnostic traces the path from source and configuration to a deployable, supportable service — build systems, hosted workflow engines, model and data services, evaluation tools, secrets, accounts, licences, and undocumented procedures — and separates assets delivered from rights granted from capabilities demonstrated. A file export can preserve data while losing behaviour, metadata, or permissions.
The ledger
A technical debt ledger is a maintained inventory of design and implementation limitations and the decisions made about them.
Restricting it to deliberate shortcuts loses most of its value. Include limitations found through learning, and record whether the choice was conscious rather than inferring intent from code written by people who have gone.
Fowler’s distinction between prudent and reckless, deliberate and inadvertent debt is the useful classification, and it comes with the permission not to repay: remediation can be not worth doing in an area that is rarely changed.
Each row carries a stable identifier and affected version, the limitation with its evidence, the decision context linked to an architecture decision record where one exists, the consequence separated into observed effects and forecasts, cost with observed rework kept apart from remediation estimates, an owner on both sides, a disposition with a trigger, and closure evidence.
Architecture decision records supply the companion structure: short entries with context, decision, status, and consequences, with superseded decisions retained and linked to their replacements rather than deleted.
Before transfer, map each item against the agreed operating requirements. A ledger entry recording that restart requires a supplier-only script blocks the restart acceptance task — listing a failure does not convert it into a pass. An awkward internal design in a rarely edited reporting module stays at investigate or retain with conditions. Neither classification implies a severity rule or a cash valuation.
The ledger’s usefulness is testable: trace sampled operational failures and changes back to current entries, and correct what is missing or stale. That checks maintenance, not completeness.
The rule
What stays fixed is that every dependency and limitation has a named owner on the receiving side. What changes is which ones matter, and that is decided by the tasks the recipient has agreed to perform rather than by the builder’s assessment of elegance.
Not to be confused with
A tool list. No language, database, or framework is boring in the abstract. Current version support, licensing, and security evidence still have to be checked for the specific candidate.
A waiver. A recipient signature on a ledger documents a decision within that person’s authority. It does not override applicable obligations, and documentation is not operational evidence.