Progress is not the amount of novelty produced. Progress is the amount of useful capability that remains available.
This article argues for a rather simple idea that is strangely unpopular in modern technical culture: stability is the basis on which nearly all real progress is built.
The fashionable picture looks different. Technology is said to move extremely fast. Companies are expected to release one feature after another, research projects are expected to produce breakthroughs inside one or two funding periods and software is expected to replace its interfaces, frameworks and sometimes its entire conceptual foundation every few years. If this creates permanent work for everyone involved it is accepted as the natural condition of a dynamic world. One frequently hears that stagnation is death, that one has to move fast and that anybody who objects simply failed to keep up.
I think this picture is fundamentally wrong.
There is of course change. There is exploration, there are prototypes and sometimes an experiment has to be performed quickly before one even knows whether an idea is useful. None of this is disputed here. But an experiment is not yet infrastructure, a prototype is not yet a product and a published result is not yet a capability society can rely on. Exploration only discovers a possible path. The actual construction of progress begins afterwards, when the useful part is made reproducible, compatible, maintainable and sufficiently stable that other people can build upon it without being forced to rebuild their own work every few months.
This distinction is essential. A rapidly changing prototype may be valuable for a short time because it produces information. If its findings are never consolidated into something stable, however, its long-term contribution approaches zero. It has consumed human lifetime and perhaps produced an interesting demonstration, but it has not increased the stock of dependable tools available to everyone else.
The best technology is therefore not necessarily the technology with the largest number of releases. It is the technology one can still use in thirty years. It may receive security fixes, performance improvements and additional features throughout this time. Stability does not require abandonment. It requires the opposite: maintenance without betrayal of the existing contract.
This article develops this argument from four directions. First, it gives a more useful definition of progress and a simple model for the cost of instability. Second, it looks at computing systems that are usually described as rapidly moving even though their success depends on interfaces preserved for decades. Third, it examines scientific and industrial breakthroughs whose apparently sudden arrival was built from long, slow chains of work. Finally, it turns the argument into practical rules for engineering and management.
The central thought extends an earlier article about automation and stability[1]. Automation compounds human time only when the automated environment remains stable. The same is true more generally: knowledge, software, machines and institutions compound only when yesterday’s useful work remains usable tomorrow.
Motion Is Not Progress
The stock of retained capability
Most discussions about technological progress use quantities that are easy to observe. Features released per quarter, commits per day, papers per year, products launched, patents filed and funding acquired all measure activity. Activity is visible and can be attributed to the people performing it. Stability, in contrast, is visible mostly through the absence of events. A protocol that keeps working does not produce an emergency meeting. A machine that requires no manual intervention does not create an impressive incident report. A program that compiles unchanged after fifteen years rarely becomes a news story.
This creates the first important measurement error. Activity is a flow, while progress is a stock.
Let $F(t)$ be the rate at which useful new capability is created. Let $L(t)$ be the rate at which existing capability is lost because interfaces disappear, formats become unreadable, dependencies break or knowledge becomes unusable. The retained stock $P(t)$ can then be written in the deliberately simple form
[
P(t) = P(0) + \int_0^t \left(F(\tau)-L(\tau)\right)\ \mathrm{d}\tau
]
An organization that produces ten units of capability and destroys nine has moved a great deal but progressed by only one. Another organization that produces three units and preserves all three has progressed three times as far. If only feature output is measured, the first organization looks more dynamic. If retained capability is measured, the second is clearly better.
This is not merely a metaphor for software. A scientific result that cannot be reproduced has a large publication flow and a small contribution to retained knowledge. A laboratory instrument that becomes unusable because its control software requires an abandoned cloud service loses physical capability even though the hardware still exists. A public database whose format changes without a reliable migration path destroys part of the value previously invested in collecting the data.
The relevant question is therefore not “How much changed?” but “What can be done now that could not be done before, without losing what could already be done?”
Local speed and global speed
The second measurement error is a confusion of system boundaries.
Suppose a library maintainer removes an old interface and replaces it with a cleaner one. The local change may take two days. From the maintainers viewpoint the project moved quickly. If ten thousand users each need twenty minutes to understand the change, update their code, test it and deploy it, the global cost is more than 3300 hours. The local team has saved perhaps a week and consumed roughly two working years elsewhere.
For an upstream component with downstream users $i=1,\ldots,N$, a first approximation of the cost of a breaking change is
[
C_{\mathrm{break}} = C_{\mathrm{upstream}} +
\sum_{i=1}^{N} p_i
\left(C_{\mathrm{understand},i}+
C_{\mathrm{modify},i}+
C_{\mathrm{test},i}+
C_{\mathrm{deploy},i}\right)
]
where $p_i$ is the probability that the changed contract affects user $i$. Even if every individual downstream cost is small, the sum may be enormous. Most organizations do not see this sum because the work appears in other budgets, other companies and the private time of users. Instability is therefore unusually easy to externalize.
Empirical studies of API evolution confirm that breaking changes propagate into real client work[8,9]. The exact measured fraction varies with language, ecosystem and what researchers can observe. Private code is usually invisible, behavioral incompatibilities are harder to detect than syntactic ones and abandoned clients disappear from samples. But the structural fact does not depend on a particular percentage: a single upstream decision can create work at every downstream edge.
The same applies inside organizations. A configuration change may be cheap for the team that owns a service and expensive for every automation pipeline that consumes it. Renaming a field may look like cleanup in the producing repository and become weeks of coordination in the whole system.
Local velocity is not global progress.
Rework is negative production
When an engineer spends a day adapting working software to a new interface without gaining a new capability, no progress has been made during that day. Existing capability has merely been restored.
This work is often counted as development because code was changed. In economic terms it is closer to replacing a road that another department dug up yesterday. The replacement may be technically necessary after the damage and the engineers performing it may do excellent work, but it does not follow that the damage was productive.
Technical debt studies repeatedly find substantial developer time lost to avoidable friction. One longitudinal study reported an average of roughly 23% of development time wasted because of technical debt[3]. The exact number should not be treated as a universal constant, but its scale matters. It shows that apparently productive organizations can consume a large share of their capacity merely overcoming conditions created by earlier development.
Googles site reliability terminology calls manual, repetitive, automatable work without enduring value “toil”[7]. This is a useful definition far beyond operations. Compatibility work forced by avoidable churn is dependency toil. Re-entering data after a format change is user toil. Rewriting a build configuration because a tool changed its vocabulary is toolchain toil. None of it is a law of nature.
The phrase “that is life”, that one often hears in this context, is therefore not an explanation. It is an admission that the cost has become culturally invisible.
Stability Is Not Stagnation
What has to remain stable
Stability does not mean that every line of source code must be frozen. It does not mean refusing security fixes, preserving known defects forever or rejecting additional features. It means preserving contracts. A contract may be:
- a function signature and its documented behavior
- a network message and its interpretation
- a file format
- an instruction set
- a connector geometry
- a unit of measurement
- a command-line invocation
- a physical mounting pattern
- a documented operational procedure
- or a promise about the continued availability of a feature
The internal implementation behind such a contract can change radically. A database may replace algorithms, add indexes, improve its query planner and harden its storage layer while continuing to open old files. A processor may use completely different microarchitecture while executing an established instruction set. A web browser may replace its rendering engine while still presenting an old page.
This is the most productive kind of change: freedom inside, stability at the boundary.
The distinction is familiar in systems engineering. NASA describes configuration management as the discipline that preserves product integrity by controlling changes to functional and physical characteristics across the life cycle[4]. The point is not to prevent every modification. It is to ensure that a modification is beneficial, understood and introduced without uncontrolled adverse consequences.
Maintenance is active work
A stable system is not a neglected system.
Real environments change. Security vulnerabilities are discovered. Hardware fails. Regulations change. New scale reveals old assumptions. Lehmans work on software evolution observes that systems embedded in a changing real world have to be adapted or they become progressively less satisfactory, while their complexity tends to increase unless work is explicitly performed to control it[2].
This does not support arbitrary interface churn. It supports maintenance.
Maintenance may require replacing an implementation, removing a vulnerability, extending an address field, adding a negotiation mechanism or writing a compatibility layer. The stable approach asks how the old contract can remain available while these improvements are introduced. Sometimes the answer is an adapter. Sometimes it is a new optional field, an additional operation, a capability query or a parallel protocol. Sometimes the old behavior can be reproduced safely on top of a completely new core.
The work is often less glamorous than a clean break. It may require understanding decisions made by people who left the project years ago. It may preserve awkward details. But this work protects the accumulated investment of every existing user.
Stability is a continuing service performed for the future.
Compatibility has more than one direction
Several forms of compatibility are often mixed together:
- Backward compatibility means a newer implementation can consume old inputs or serve old clients.
- Forward compatibility means an older implementation can tolerate some newer inputs, usually by ignoring what it does not understand.
- Source compatibility means old source code can still be compiled.
- Binary compatibility means an old executable or library client still runs.
- Behavioral compatibility means the same input retains the meaning on which users relied.
- Data compatibility means stored information remains readable and correctly interpreted.
- Physical compatibility means components continue to fit and communicate mechanically or electrically.
A project can preserve one while breaking another. A library may compile old code yet subtly alter behavior. A file may remain parseable while changing units. A connector may fit physically while supplying an unsafe voltage. Long-term engineering has to state the contract precisely rather than using the word compatibility as decoration.
For the purpose of this article, stability means that established useful behavior remains available unless preserving it would create a demonstrable and disproportionate danger. “We prefer the new design” is not such a danger. “The old path requires maintenance” is not such a danger either; that maintenance is part of the cost accepted when other people were encouraged to build on the path.
Major versions do not remove the cost
Semantic versioning is useful communication. A major version number can warn users that an interface changed. It does not make the change free.
If a bridge is closed, a sign warning drivers about the closure is better than no sign. The sign does not restore the bridge. In the same way, calling a release 5.0 rather than 4.9 may prevent surprise, but every downstream migration still consumes human lifetime.
Versioning is therefore a last line of communication, not a license to break. A well-maintained long-lived product should be proud of how rarely it needs a destructive major transition. If a new architecture is truly incompatible, it can often be offered beside the existing one rather than being declared its immediate replacement.
The strongest compatibility policy is not “we label breakage correctly”. It is “we avoid requiring it”.
The Hidden Economy of Breakage
The dependency graph
Modern technical systems are graphs, not lists.
An application depends on libraries. Libraries depend on runtimes. Runtimes depend on operating-system interfaces. Services depend on protocols, identity providers, databases, message formats and deployment systems. Scientific software additionally depends on numerical conventions, calibration files, instrument firmware, data schemas and analysis environments.
If node $j$ has downstream dependants $D(j)$, the immediate adaptation work caused by changing its contract is distributed across $D(j)$. But each dependant may itself expose another contract. A rushed adaptation can therefore propagate defects, version constraints and temporary workarounds into further layers.
This is why instability grows faster than the number of changed lines suggests. The cost follows graph reachability.
The designers of large systems have understood this for a long time. The System/360 architecture explicitly separated architecture from implementation so machines with very different performance could present a compatible programming model[18]. Internet architecture hid routing evolution from hosts and required interoperability across diverse networks[14]. These were not aesthetic choices. They were methods for preventing the dependency graph from becoming globally synchronized around every local change.
The pinning trap
When updates are risky, users pin versions. This is rational locally and dangerous globally.
A pinned dependency prevents an unexpected breaking change today. It also prevents automatic delivery of security fixes and reliability improvements tomorrow. The user is forced to choose between known stagnation and unknown migration work. Eventually several pinned layers interact, and upgrading one requires upgrading all of them together. The cost grows until it is postponed again.
This is sometimes presented as evidence that old software is the problem. Usually it is evidence that the upgrade path is untrustworthy.
In a stable ecosystem, users can accept routine fixes because the contract remains intact. The new implementation becomes safer and faster while the client remains unchanged. Automatic upgrading becomes possible precisely because compatibility reduces the expected migration cost.
Instability therefore blocks one of the main benefits often claimed for rapid delivery. A release pipeline can publish every hour, but users cannot safely consume those releases if each one may invalidate their systems.
Security is not an argument for churn
Security is frequently used as a universal excuse for incompatibility. Sometimes an old behavior really is inseparable from a vulnerability. Cryptographic algorithms can become inadequate, authentication methods can expose credentials and unsafe parsers may need stricter rules. In such cases a transition is necessary. But the existence of necessary exceptions does not justify making breakage routine.
A security transition can be designed with capability negotiation, dual operation, warnings, measured deprecation, migration tools and long overlap periods. Stored data can be rewritten automatically. Old clients can be isolated behind a compatibility gateway. The unsafe part can be removed while preserving unrelated behavior.
More importantly, unstable ecosystems create security problems of their own. If users fear updates, vulnerable versions remain deployed. If upgrades require manual rewrites, patches arrive late. If dependency trees cannot be reproduced, nobody knows which fix is actually running. Compatibility and security are therefore usually allies.
The ideal security update is boring: the implementation changes, the vulnerability disappears and the user notices nothing.
The maintenance paradox
There is a common claim that compatibility creates maintenance burden. This is true in the narrow sense. Supporting an old contract requires tests, documentation and sometimes additional code.
The missing question is: maintenance burden for whom?
Removing a compatibility path transfers work from the small upstream team, which knows the system, to a potentially enormous number of downstream teams, which do not. The total cost usually increases even if the producer’s cost decreases. What appears as simplification in one repository becomes complexity across the ecosystem.
This is especially perverse when the upstream organization is funded, visible and technically specialized while downstream users are researchers, small companies, public institutions or individuals. The party most able to solve the compatibility problem once delegates it to thousands of parties that must each solve a fragment.
A stable project accepts an asymmetric responsibility: centralize compatibility work where knowledge is concentrated, so everybody else can keep using the system.
The Fast-Moving Computer That Barely Moves
A machine made from old promises
A modern computer looks like a symbol of rapid technological change. Processor generations, operating-system releases, programming languages and web frameworks arrive continuously. Yet the machine is useful because its lower contracts move extremely slowly.
A program opens a file through operating-system calls whose conceptual ancestry reaches back decades. It sends data through TCP, standardized in 1981[15] and resolves names through DNS specifications published in 1987[16]. It may be written in C, use POSIX interfaces, store images in JPEG and produce PDF documents. None of these foundations is new. Their age is not a weakness. Their age is why they can be trusted as foundations.
The visible surface moves because the invisible base does not.
Unix, POSIX and the value of a boring interface
Unix-like systems vary internally. Kernels have been rewritten, schedulers replaced, storage systems added and hardware architectures changed. Still, a large class of programs can be moved between systems because the process, file-descriptor and stream abstractions remain recognizable.
POSIX did not freeze every operating system into one implementation. It standardized a useful boundary[17]. This allowed competition below the boundary and portability above it. A shell script or C program written against a conservative subset can survive hardware generations and vendor changes because the contract is more durable than any one machine. Linux makes the distinction particularly clear. Its internal kernel interfaces are intentionally free to evolve, while userspace interfaces receive explicit stability treatment. The kernel documentation states that most interfaces such as system calls are expected never to change and always to remain available[11].
This policy is not evidence that Linux stopped developing. Linux changes constantly. It supports new processors, filesystems, security mechanisms and devices. Its success demonstrates the opposite relationship: extensive internal evolution is sustainable because established userspace contracts are protected.
System/360 and the invention of architectural time
IBM announced System/360 in 1964 as a compatible family spanning a wide performance range. The original architecture paper emphasized strict upward and downward machine-language compatibility across models[18]. IBM’s historical account describes the replacement of several incompatible product lines by a unified software-compatible architecture[19].
The important invention was not only a particular instruction set. It was the separation of architecture from implementation.
Once software targeted the architecture rather than the physical details of one machine, processors could be made faster, larger or internally different without invalidating the software investment. Microcode could reproduce instructions. New models could extend capacity. Customers could move through the product family without rewriting everything.
This created architectural time: the lifetime of the interface became longer than the lifetime of each implementation.
Modern instruction-set families use the same principle. An old binary is not forced to understand superscalar execution, speculative pipelines, caches or semiconductor process changes. These are internal matters. The binary sees the established machine model.
Compatibility is sometimes mocked as historical baggage. In this case the baggage is the accumulated software value that made the architecture worth buying.
Ethernet and the Internet
Ethernet evolved from early megabit networks to standards covering hundreds of gigabits per second while retaining a common media-access layer model[20]. Cables, transceivers and encoding methods changed. Switches replaced shared collision domains. The useful identity of Ethernet survived.
The Internet provides an even stronger example. RFC 1122 described requirements for hosts across diverse and changing networks and explicitly aimed to insulate host software from evolution in the routing architecture [14]. This separation allows applications to communicate without knowing whether packets cross copper, fiber, radio links, tunnels or satellite systems.
The Internet did not become globally useful because every layer was replaced whenever a better local idea appeared. It became useful because new links and applications could be added around a stable packet-delivery core.
Even the incomplete transition from IPv4 to IPv6 illustrates how strong installed contracts become. A theoretically cleaner replacement cannot simply order the world to migrate. Dual stacks, translation mechanisms and long coexistence are required because the network is not a laboratory. Billions of independently operated systems are part of the contract.
The web preserves its mistakes
HTML is often described as fast-moving web technology. Browsers update frequently and new APIs are added continuously. Yet the webs unusual success depends on the expectation that old pages keep rendering.
The HTML design principles place support for existing content at the beginning of their compatibility discussion. They require implementations to handle documents that depend on older specifications, proprietary behavior and even historical error handling[13]. This is not theoretically beautiful. It is operationally brilliant.
The web treats deployed content as part of reality. A standards committee cannot edit every old page, so new browsers absorb much of the compatibility burden. The result is that documents created decades ago remain accessible while the same platform gains video, graphics, accessibility features, cryptography and complex applications.
A competing design that was conceptually cleaner but invalidated the existing web would have been less progressive, because it would have destroyed more retained capability than it created.
SQLite and an explicit promise to the future
SQLite states an intention to be supported through 2050 and promises backward compatibility for both its C API and on-disk format[12]. The formulation is unusually direct: applications written today should be able to link against future versions, and data stored today should remain accessible to future generations.
This is what a serious technology promise looks like.
SQLite still gains features and fixes. Query planning improves. Platforms change. The long-term contract constrains how these changes are introduced but does not prevent them. Instead, it gives users confidence to embed the database in systems expected to live longer than the present development team.
The promise also improves engineering decisions today. A format intended to survive decades encourages explicit encoding, careful corruption handling, strong tests and conservative semantics. Long-term intent is not only a support policy. It changes the quality of the design.
Standards Are Machines for Accumulating Work
Compatibility creates network value
The value of many technologies depends on the number of compatible complements around them. A communication protocol becomes more useful as more systems speak it. A file format becomes more useful as more tools read it. A connector becomes more useful as more devices fit it. Economic work on network externalities and standardization formalized these effects decades ago[39,40].
The important consequence is that compatibility produces value even when no individual component improves.
If a new editor can open all existing documents, it inherits a document ecosystem. If it requires a new format, it begins with an empty world. If a new musical instrument speaks the established protocol, it can interact with old instruments and software immediately. If it speaks only a new protocol, its individual technical superiority may be irrelevant.
Standards are therefore not bureaucratic obstacles placed after innovation. Good standards are machines that allow independently produced work to combine.
MIDI: Four decades of musical machinery
MIDI 1.0 dates from the early 1980s. Its bandwidth and resolution reflect that time, yet it remains embedded in instruments, controllers, studios and software. MIDI 2.0 adds richer messages and bidirectional capabilities while using an architecture designed for backward compatibility and translation[22].
This is the correct response to a successful old interface.
The limitations of MIDI 1.0 are real. They justify an extension. They do not justify making every existing keyboard, synthesizer and composition tool worthless. MIDI 2.0 gains immediate practical relevance precisely because it can coexist with the installed base.
The standard moved slowly, and because it moved slowly an enormous amount of creative and industrial activity could move quickly around it.
JPEG and PDF
JPEG compression was standardized in the early 1990s[23]. The format is far from perfect for every modern imaging task. New codecs achieve better compression, support high dynamic range and handle different content more effectively. Still, almost every relevant system can decode ordinary JPEG images.
This universality is itself a capability. An image can pass through cameras, websites, archives, scientific tools and operating systems without negotiating a vendor-specific world. New formats can be added beside JPEG where their advantages matter. The old images do not have to disappear.
PDF follows a similar pattern. It was designed to preserve document presentation across software and hardware and later moved into ISO standardization[24]. The ecosystem is complex and not every PDF feature is equally archival, but the stable idea of a self-contained portable document has survived platform generations.
The value of these formats cannot be measured only by compression efficiency or feature count. It includes every avoided conversion, every document that remains readable and every implementation that can interoperate without asking the original author for help.
USB and physical continuity
USB has accumulated several naming mistakes and connector transitions, and it should not be idealized. Nevertheless, its specifications illustrate the deliberate use of layered compatibility. Newer transfer modes and power capabilities have repeatedly been introduced while retaining ways for older devices to communicate[21].
This matters because physical devices have longer and more irregular lives than software releases. A laboratory instrument, keyboard, serial adapter or measurement device may remain perfectly useful for decades. Replacing it because a software company prefers a new abstraction is waste.
Where physical connector changes are unavoidable, adapters and protocol continuity preserve part of the investment. Where they are merely fashionable, they convert functional hardware into electronic waste.
The LEGO test
The LEGO System in Play expressed a compatibility promise in unusually tangible form: elements from yesterday, today and tomorrow should fit together[41]. The modern stud-and-tube brick dates to 1958, yet later sets add an enormous variety of shapes, mechanisms and themes without invalidating the elementary geometry.
This is more than a charming toy example. It is almost a perfect demonstration of an extensible interface.
The stable connection rule creates a combinatorial design space. Every new element can combine with old elements, so the value of the whole system grows faster than the catalogue. A hypothetical annual connector redesign might permit locally elegant pieces, but it would destroy the system.
Software APIs should be judged by the same simple question: will the new piece still connect to what users already own?
Apparently Sudden Technology
The launch-date illusion
Products have launch dates. Foundations usually do not.
A product is announced on a stage, photographed and sold. The date becomes a convenient point in history. The enabling work is distributed across earlier decades, organizations and disciplines, so it is harder to narrate. This produces the illusion that technology arrives suddenly.
The first iPhone was announced in January 2007 as a phone, media player and Internet communicator using a multi-touch interface[25]. As a product integration it was highly significant. It was not created from technologies invented during the months before the announcement.
It depended on mature cellular networks, semiconductor manufacturing, battery chemistry, capacitive sensing, radio engineering, operating systems, web standards, audio and video codecs, flash storage and global manufacturing. Each layer represented many decades of work. More importantly, each layer was usable because it exposed sufficiently stable properties to the designers above it.
The product appeared fast because the foundations had become boring.
Integration is real innovation
Pointing out the age of the foundations does not diminish the work of integration. Combining mature components into a coherent product is difficult. Interfaces have to be reconciled, constraints balanced and manufacturing made reliable.
But integration reinforces rather than weakens the stability thesis.
An integrator cannot build a complex product if every lower layer changes unpredictably during development. Mechanical dimensions, radio behavior, processor interfaces, toolchains and protocols have to remain stable long enough for the whole to be tested. After launch, application developers need the product platform to preserve their investments as well.
The apparently fast product is therefore a temporary convergence of slow-moving layers.
Artificial intelligence did not appear in one year
Modern artificial intelligence is another strong example of compressed public history.
Back-propagation was famously demonstrated for learning internal representations in 1986[26], building on earlier work in neural computation and optimization. Convolutional networks developed over decades. Large labeled datasets, better hardware and GPU implementations made much larger experiments practical; the 2012 ImageNet result was a prominent turning point[27]. The transformer architecture was published in 2017[28]. Reviews of deep learning already described the long convergence of representation learning, compute and data before the present wave of generative products[29].
From a media viewpoint, a chatbot may seem to transform the world during a single release season. From a scientific viewpoint, it is one visible output of a long accumulation.
Even after the visible breakthrough, a durable capability is not finished. Models have to become reproducible, efficient, inspectable and supportable. Data and evaluation practices have to mature. Interfaces need to stop changing arbitrarily. Applications require predictable behavior, versioned semantics and local fallbacks. Hardware and runtimes need stable execution paths.
Without this consolidation, an impressive model remains an expensive experiment surrounded by permanent integration work.
The danger of confusing a demonstration with a foundation
A demonstration answers “Can this be done at least once under these conditions?” Infrastructure answers a different question: “Can other people depend on this without the original team standing beside it?”
The gap includes:
- reproducibility
- failure handling
- documentation
- compatibility
- performance bounds
- security maintenance
- supply chains
- calibration
- test coverage
- data preservation
Media reports often collapse this gap. Management plans then inherit the compressed timeline. A research demonstration is expected to become a production system during the next quarter. When the missing engineering consumes years, it is treated as delay rather than as the main body of the work.
The prototype was not ninety percent complete. It answered a smaller question.
Science Moves at the Speed of Evidence
Projects are slices through longer work
Scientific funding is organized into projects because budgets seem to require boundaries. Nature, and thus reality, does not respect these boundaries.
A two-year project may test one hypothesis, build one instrument or collect one dataset. The idea often began way before the proposal, relies on methods developed by others and produces questions that continue after the final report. Publication may require additional controls, repeated measurements, analysis, peer review and revision. Adoption by other groups requires independent reproduction and usable methods.
For a medium-sized scientific idea, half a decade from first serious work to a mature publication is entirely unsurprising. For large ideas, the relevant time scale may be a whole career.
This does not mean scientists work slowly in the everyday sense. Individual experiments may be performed quickly. Code may be written in days. The long duration comes from the number of uncertain steps and the fact that reality can reject every convenient schedule.
Science is not a feature factory. Its output is justified belief, and justification takes time.
mRNA vaccines
The COVID-19 mRNA vaccines were developed and deployed with exceptional urgency. Their visible success in 2020 is often used as an example of extremely fast science.
The platform was not invented in 2020.
Research into mRNA, delivery and immune response had been progressing for decades. Kariko, Weissman and colleagues published the effect of nucleoside modification on innate immune recognition in 2005[31]. The Nobel scientific background describes how these discoveries enabled effective mRNA vaccines when the pandemic created an urgent application[30].
The rapid final response was possible because the slow foundation already existed. Sequencing, lipid nanoparticles, manufacturing processes, trial methods, regulatory institutions and global logistics were also available. The last stage moved quickly because many earlier stages had been stabilized.
Calling only the final year “the development” erases the work that made speed possible.
Lithium-ion batteries
Lithium-ion batteries are associated with fast-moving consumer electronics and electric vehicles. Their development story spans decades.
Whittinghams work on intercalation cathodes emerged in the 1970s. Goodenough developed a higher-potential cobalt-oxide cathode around 1980. Yoshino developed a safer carbon-based anode and a commercially viable cell in the 1980s. Commercial introduction followed in the early 1990s. The Nobel background traces this sequence and the different technical obstacles solved along the way[32].
The mobile products of the 2000s depended on electrochemistry consolidated over the preceding decades. Continuing improvements in materials, manufacturing, safety and battery management then accumulated without requiring every device engineer to rediscover the cell.
The progress was not one breakthrough. It was a stable chain of solved constraints.
CRISPR
CRISPR gene editing also looked sudden when programmable Cas9 systems became widely usable. The underlying biological patterns had been observed long before their function was understood. Work across microbiology, genetics and biochemistry gradually established CRISPR as an adaptive immune system. Jinek and colleagues demonstrated a programmable RNA-guided DNA endonuclease in 2012[34], and the Nobel scientific background places this result within the longer discovery chain[33].
After the programmable mechanism came another long chain: delivery, off-target analysis, organism-specific methods, clinical trials, manufacturing, ethics and regulation.
Again the distinction is important. A method that edits DNA in a controlled laboratory experiment is a major result. It is not yet a routine, safe and broadly available therapy. Treating these as the same stage creates unrealistic promises and bad policy.
Gravitational waves
Einsteins theory predicted gravitational waves roughly a century before their first direct observation. The LIGO collaborations 2016 publication reported a signal observed in September 2015 and explicitly described the detection as occurring a century after the fundamental theoretical predictions[35].
The delay was not intellectual inactivity. It was the time required to make an almost impossibly precise measurement reliable.
Laser stability, mirror coatings, vibration isolation, vacuum systems, control theory, numerical relativity, data analysis and large-scale scientific coordination all had to advance. Early detector generations could operate correctly and still observe no event. Their value included learning how to build the next generation.
Calling the final detection a sudden breakthrough is understandable as storytelling. As an engineering description it is incomplete. The signal became visible because decades of stable intermediate capabilities were assembled.
Discovery, publication and use are different clocks
There is no universal translation time from research to practice. Different fields have different constraints. A mathematical result can be distributed as a paper; a medical treatment requires safety evidence, production and clinical systems; a new material may require an industrial supply chain.
Still, empirical work on medical translation found that time lags commonly discussed under the famous “17 years” summary arise from several distinct stages and definitions[36]. The number should not be turned into another simplistic rule. Its value is that it destroys the fiction that discovery and routine use are nearly simultaneous.
Three clocks should be kept separate:
- Discovery time: the work required to establish that an effect or method exists.
- Consolidation time: the work required to reproduce, explain and delimit it.
- Deployment time: the work required to make it safe, scalable, affordable and maintainable.
Only media time is instantaneous.
The Physical World Is Built from Frozen Decisions
A box that changed trade
The standardized freight container is mechanically unexciting. It is a box with carefully controlled dimensions, ratings and handling points. ISO 668 still defines the classification and principal dimensions of the Series 1 containers around which ships, cranes, trucks, rail wagons, ports and warehouses are designed[37].
The economic effect was anything but unexciting. Empirical analysis associates container adoption with major growth in international trade and emphasizes that containerization required complementary technological and organizational changes[38].
The crucial object was not merely the box. It was the stable interface between transport systems.
Before standardization, cargo handling was repeatedly adapted to ships, ports and local practices. After standardization, an independently packed unit could move through a global intermodal network. Crane manufacturers could design for the same geometry as shipyards. Truck builders could design for the same unit as ports. Warehouses could arrange storage around known dimensions.
If the container interface had been improved incompatibly every two years, this network could never have accumulated. A slightly better box would have produced a much worse transport system.
Units are infrastructure
The International System of Units is another foundation that works by refusing arbitrary local invention. The SI has been refined - for example by defining units through physical constants - but the practical continuity of measurements is treated as essential[42].
Imagine an engineering culture that renamed units, changed scale factors or altered sign conventions at the pace of web frameworks. Every drawing, calibration, material specification and instrument would become a migration project. Bridges would not become innovative. They would become dangerous.
Measurement standards show that stability does not oppose scientific improvement. Metrology advances continuously. Realizations become more precise. The external quantity remains sufficiently continuous that earlier measurements retain meaning.
This is the physical equivalent of replacing an implementation behind a stable API.
Long-lived equipment and the software problem
Physical equipment frequently outlives the software fashion surrounding it.
A microscope, lathe, power supply, spectrometer, environmental chamber or industrial controller may remain useful for more than hundred years. Its bearings can be replaced, electronics repaired and calibration renewed. Increasingly, however, the machine is made dependent on short-lived software: a proprietary operating-system driver, an online activation service, an undocumented file format or a vendor cloud endpoint.
The result is a reversal of expected lifetimes. A mechanically sound instrument becomes waste because a much cheaper software layer was not designed to survive.
This is not progress. It is the destruction of capital through interface negligence.
A serious instrument should therefore provide documented protocols, stable command sets, local operation, exportable calibration data and replaceable control software. Network features may be added, but the machine should not require a remote service for basic function. The goal is not to preserve every original computer. It is to make the control boundary sufficiently open and stable that a future computer can take its place.
Repairability is compatibility across time
Repair is usually discussed as a question of spare parts and access. At a deeper level it is temporal compatibility.
A replacement part must fit the old mechanical interface. A diagnostic tool must understand the old protocol. Documentation must still describe the deployed revision. Firmware must remain obtainable. A new component may improve efficiency or reliability, but it should reproduce the relevant contract of the old component.
Products designed this way can evolve by substitution. Products designed as sealed historical moments fail as soon as one layer ages.
The same principle applies to organizations. If knowledge exists only in the memory of one employee, the organization has an undocumented interface. If a process works only through one person’s manual intervention, it has no stable operational contract. Succession, documentation and automation are forms of repairability.
The environment also pays
Breaking software is often treated as immaterial because no physical object is visibly destroyed. Yet software instability causes hardware replacement, repeated computation, travel, emergency work and duplicated development. It consumes energy and materials through secondary effects.
The cleanest environmental product is often not the device with the most impressive new efficiency figure. It is the device that remains in service.
Long-lived products distribute their manufacturing cost over more useful years. Stable protocols allow controllers and computers to be replaced without replacing sensors, motors and structures. Additive upgrades preserve embodied energy. A compatibility layer that extends the life of ten thousand instruments may have greater environmental value than a new green product line.
Durability is not nostalgic. It is resource efficiency.
Exploration Has One Job
Learning under uncertainty
Exploration is necessary because the correct design is not always known in advance. At the beginning of a project it may be rational to write disposable code, change data structures repeatedly and test several incompatible approaches. Scientific instruments are often assembled from improvised parts before the relevant signal is even known to exist. A new algorithm may need synthetic experiments before its useful parameters are understood.
This is the legitimate domain of moving fast.
But the output of exploration is information, not infrastructure.
The prototype should answer questions:
- Does the effect exist?
- Which constraints dominate?
- Which interface is actually useful?
- What fails?
- Which parts need to remain flexible?
- What can be specified?
Once those answers exist, the engineering mode has to change.
The consolidation boundary
The most damaging projects never declare the point at which experimentation ends and dependence begins.
A prototype acquires users. Its accidental data format becomes a public format. A temporary API is copied into production. A research script becomes a service. Because the system is still culturally labeled experimental, maintainers feel free to change it. Because other people now depend on it, every change creates real downstream cost.
The project has crossed the consolidation boundary without acknowledging it.
This boundary should be explicit. Before crossing it, interfaces may be unstable and users must not be encouraged to build durable systems on them. After crossing it, contracts are versioned, documented, tested and treated as obligations. Internal experimentation can continue behind them.
A useful rule is:
If another independent person is expected to invest substantial work against an interface, the interface is no longer an experiment.
Beta written in a header for five years does not change this reality.
Throw prototypes away-or finish them
Prototype code has accumulated assumptions optimized for learning speed. It may omit error handling, portability and migration. Turning it directly into infrastructure often creates the technical debt originally described by Cunningham: the apparent speed gained by an incomplete design produces interest in later work[5].
There are two honest choices:
- discard the prototype after extracting what was learned and implement a stable system
- stop treating it as disposable and perform the work required to make it durable
The dishonest choice is to deploy the prototype, call it production, retain experimental instability and make users pay the resulting interest.
This is especially important in machine learning. Sculley and colleagues described how small amounts of ML code can sit inside large systems of data dependencies, configuration, monitoring and glue, creating hidden technical debt[6]. A model demonstration may be quick. A reliable system that knows when the model is wrong is not.
Exploration and exploitation are not symmetric
Organizational research distinguishes exploration of new possibilities from exploitation of established knowledge[43]. Both require resources and a system that performs only one becomes unhealthy.
For the argument here, however, they do not have equal final status.
Exploration creates options. Consolidation and stable exploitation turn selected options into retained capability. Ten experiments may reasonably fail. The useful eleventh must then be made dependable. If all resources are moved immediately to the next experiment, the organization accumulates demonstrations rather than progress.
This explains a common paradox in research and technology companies. They appear highly innovative because they announce many prototypes, yet their users solve the same integration problems year after year. Novelty is produced, but it never settles into a foundation.
Exploration is valuable only because something may eventually stop exploring.
Two lanes, not one compromise
The best organization does not force the same stability policy onto every activity. It maintains two lanes.
The exploratory lane is explicitly temporary:
- no compatibility promise
- small user population
- easy reset
- strong recording of results
- and a defined question being tested
The foundation lane is explicitly durable:
- documented contracts
- compatibility tests
- migration planning
- operational ownership
- security support
- and a long time horizon
Ideas can move from the first lane to the second, but they pass through a consolidation step. Production users are not used as involuntary experimental instrumentation. This separation permits fast learning without normalizing a fragile world.
Why Organizations Reward Instability
Visible work wins
Stable systems create a political problem: their value is counterfactual.
One cannot easily photograph the outage that did not happen. The manager who funds compatibility testing cannot present a dramatic rescue. An engineer who removes a recurring manual task may make their future workload appear smaller. In contrast, a feature launch has screenshots, deadlines and a release announcement. A crisis has meetings, urgency and identifiable heroes.
Organizations therefore tend to reward visible production and visible recovery more than invisible prevention.
This does not require malicious management, only incapable one. It follows from short reporting periods and poor metrics. If work is counted rather than eliminated work measured, instability can create its own evidence of importance.
The team that causes repeated migrations may look busy. The team whose interface has required no migration for fifteen years may look inactive.
Feature accounting
Feature counts treat every addition as positive and almost never subtract the complexity imposed on users.
Suppose a release adds five features, changes three workflows and removes two established capabilities. A launch presentation can count five. The lost habits, updated documentation, retraining, automation changes and accessibility regressions are dispersed and usually absent from the ledger.
A better release balance is
[
\Delta V =
V_{\mathrm{new}}
- C_{\mathrm{migration}}
- C_{\mathrm{lost\ capability}}
- C_{\mathrm{future\ maintenance}}
- C_{\mathrm{cognitive\ change}}.
]
The new value $V_{\mathrm{new}}$ should include actual user benefit rather than the existence of a new control. The costs should be counted across all affected users, not only inside the producing team.
Under this accounting, many celebrated releases become negative.
The deadline creates a biased experiment
Short deadlines systematically favor visible incomplete work.
Compatibility design, documentation, long-duration testing and migration tooling have costs today and benefits later. Cutting them helps the present milestone. The downstream failure occurs after the launch and may be assigned to support, operations or the user.
This is a temporal externality. Present management spends future engineering time.
The same distortion appears in science when funding rewards papers within a project period but not the maintenance of datasets, instruments and software afterwards. A new prototype is attributable to the current grant. Ten years of stable operation is distributed across later users and may have no obvious owner.
Organizations obtain exactly the time horizon they reward.
Firefighting as organizational theater
Incident response is necessary after an incident. It should not be confused with the creation of value.
If engineers repeatedly repair the same category of failure, the system is consuming them. The correct goal is to eliminate the failure class, automate recovery or redesign the unstable boundary. Googles description of toil emphasizes that work which scales linearly with service growth has no enduring value[7]. A system that needs proportionally more human attention as it succeeds is not successfully automated.
The cultural difficulty is that permanent elimination also eliminates future opportunities for heroism.
Management has to reward the person who makes the alarm silent, not only the person who answers it at three in the morning.
Speed metrics already know they need stability
Modern software delivery research is sometimes invoked to demand more releases. This is an incomplete reading.
DORA evaluates delivery performance using measures that include change failure and deployment rework, not frequency alone[10]. A deployment that requires a rollback, hotfix or unplanned corrective deployment is evidence of instability. Fast delivery and low failure can coexist when changes are small, automated and well tested. Nothing in this requires breaking public interfaces.
An organization may deploy internal implementations many times per day while keeping client contracts stable for decades. In fact, stable boundaries make frequent internal deployment safer because fewer independent systems have to move in lockstep.
The real opposition is not slow versus fast. It is accumulated progress versus accumulated rework.
Measuring What Actually Matters
Retained capability
The first metric should be brutally simple:
What useful capability from last ten years is still available without mandatory user work?
This can be measured through compatibility suites, old input corpora, archived client binaries and repeatable workflows. A project should regularly test:
- whether old files still open
- whether old clients still communicate
- whether documented commands retain meaning
- whether previous automation still runs
- whether users can upgrade without migration
- and whether data can be exported without the original service
These tests turn stability from an aspiration into an observable property.
Human intervention rate
Automation is valuable because it removes repeated human work[1]. Its failure can be measured by intervention frequency.
For an operational system, record:
[
I = \frac{\text{unplanned human interventions}}{\text{unit of useful operation}}
]
The denominator may be transactions, instrument hours, deployments, samples, users or months. A maturing system should drive $I$ downward. If feature growth drives it upward, the system is becoming less advanced even if its feature list grows.
Long unattended operation is a more meaningful achievement than frequent dashboard activity.
Downstream hours caused
Every breaking change should carry an estimate of downstream work:
- number of affected clients
- expected understanding time
- modification time
- validation time
- deployment time
- training and documentation changes
- and probability of missed or abandoned migrations
The estimate will be uncertain. Uncertainty is not a reason to record zero.
The producing team should own this cost in its decision process even when another organization performs the work. If the estimated global migration cost exceeds the cost of maintaining a compatibility path, the compatibility path is the economically rational choice.
Age is not a defect count
Projects often use dependency age as a proxy for danger. Age can correlate with missing security fixes, but it can also indicate maturity.
A better inventory distinguishes:
- known vulnerabilities
- unsupported implementations
- untested contracts
- environmental incompatibilities
- merely old but functioning components
Replacing an old component without a concrete defect introduces change risk and discards accumulated operational knowledge. The replacement needs evidence of positive net value, not youth.
Old and unmaintained is a problem. Old and maintained is infrastructure.
Stability budget
Projects routinely allocate performance budgets, memory budgets and financial budgets. They should also allocate a stability budget.
The budget constrains:
- number of mandatory migrations
- allowed incompatibilities
- user-visible workflow changes
- format conversions
- removals of established behavior
Spending the budget requires justification and mitigation. Unused budget is not failure to innovate. It is preserved trust.
For foundational components, the target budget may be zero for ordinary releases.
Thirty-year questions
Before adopting a technology, ask:
- Can the data be read without the original vendor?
- Is the interface documented?
- Can the implementation be replaced?
- Is local operation possible?
- What happens if updates stop?
- Can security fixes be applied without changing user workflows?
- Are old inputs part of automated tests?
- Is there an explicit compatibility policy?
- Does the business model benefit from forced replacement?
- Would this still be usable if the present development team disappeared?
These questions are not pessimistic. They determine whether present work can become future capital.
How to Build Technology for Thirty Years
Freeze the boundary late enough-and then mean it
An interface frozen before its problem is understood may preserve the wrong abstraction. An interface left unstable after adoption prevents accumulation. Timing matters.
Before publication:
- build several real clients
- test the smallest useful operations
- observe failure modes
- separate policy from mechanism
- identify which dimensions are likely to grow
Then define the contract and treat it as an obligation.
The cost of careful interface design is paid once. The cost of careless design is paid by every client.
Prefer additive evolution
New capabilities should normally be added rather than substituted.
Useful mechanisms include:
- optional fields with defined defaults
- new operations beside old operations
- capability discovery
- extension namespaces
- reserved bits and identifiers
- length-prefixed structures
- tolerant reading with strict writing
- adapters
- explicit negotiation
An additive interface lets old clients continue using the subset they understand. New clients gain new capability without demanding synchronized migration.
Care is still required. Optional behavior can become ambiguous, and permissive parsing can create security problems. The goal is not to accept arbitrary input. It is to design extension points deliberately.
Make the data outlive the program
Data often matters longer than the software that created it.
A durable format should have:
- a public specification
- explicit byte order and numeric representation
- units and coordinate systems
- checksums where corruption matters
- version and extension mechanisms
- test vectors
- more than one implementation where practical
- export into simpler archival representations
Schema migrations should be automated, reversible where possible and tested against real historical data. Never require users to reconstruct a chain of obsolete application versions merely to reach the current format.
SQLites long-term promise for its on-disk format is a model because it recognizes that stored information is the user’s asset, not an implementation detail[12].
Preserve behavior, not only syntax
Compilation tests catch only part of compatibility.
A stable function can retain its name and change rounding, ordering, timeout behavior, units or error semantics. For scientific and control software, such changes can be worse than an obvious compile failure because they silently alter results.
Compatibility testing should therefore include:
- golden outputs
- numerical tolerances justified by the domain
- property tests
- historical bug cases
- timing and resource bounds where clients depend on them
- error behavior
- end-to-end tests with old clients
If a historical behavior is a genuine bug, first determine whether users may rely on it. A corrected operation can be added while the old one remains reproducible, or a transition can be made explicit and detectable. Silent reinterpretation is the worst option.
Keep specifications independent of implementations
An interface documented only by its current source code is not a durable interface.
The specification should describe observable behavior independently. Reference implementations and conformance suites can then test replacements. This allows internals, languages, operating systems and maintainers to change without destroying the contract.
Open standards such as Internet RFCs demonstrate the value of this separation[14,15,16]. Independent implementations are not duplication for its own sake. They reveal hidden assumptions and reduce the risk that one codebase becomes the only executable specification.
Own adapters centrally
When an internal redesign is beneficial, the team introducing it should normally provide the compatibility adapter.
This centralizes knowledge and allows one well-tested translation instead of thousands of improvised migrations. The adapter may eventually become the permanent public boundary while internals continue to evolve behind it.
Performance arguments should be measured. Many compatibility paths are cheap compared with network, storage or user interaction costs. Where overhead is real, provide a new optimized path without removing the dependable path by default.
Maintain simple escape routes
Long-lived systems need ways out.
Users should be able to:
- export their data
- run core functions locally
- replace a service endpoint
- inspect configuration
- recover without a vendor account
- operate a reduced feature set when optional infrastructure disappears
An escape route reduces the probability that one failed organization destroys an otherwise useful technical system.
This is particularly important for research. A published result should not depend exclusively on a temporary commercial API or an unarchived model. The complete original environment may be impossible to preserve, but the data, method and relevant contract can be.
Budget for maintenance before launch
A product without a maintenance plan is a deferred disposal decision.
Before users are recruited, decide:
- who owns security fixes
- how long the contract will be supported
- how archival releases are stored
- what happens when maintainers leave
- how keys and signing infrastructure are transferred
- and how users are informed if support genuinely must end
The support horizon should match the expected life of the systems built on top. A library used in embedded equipment cannot honestly offer the same horizon as an experimental visualization package.
Trust begins before version 1.0.
Typical Objections
Stagnation is death
For a living system, refusing to respond to a changed environment can indeed be fatal. But stability is not refusal to respond.
A stable system fixes faults, improves internals, adds capabilities and adapts its implementation. It simply preserves useful contracts while doing so. The biological analogy actually supports this: an organism replaces molecules continuously while preserving enough organization to remain the same organism.
Breaking existing usage is not proof of adaptation. Often it is proof that adaptation was delegated to the user.
We would be trapped by bad early decisions
Compatibility creates constraints. That is the price of accepting dependence from others.
The answer is careful pre-release exploration, narrow public contracts and strong internal abstraction. If a poor contract has already escaped, adapters and parallel interfaces are usually preferable to forced migration. Sometimes a clean break is unavoidable, but “clean” describes the new design, not the global transition.
A new system can be offered beside the old one. It earns adoption by providing enough value to justify voluntary migration. If it cannot do that, destroying the old system is not innovation; it is coercion.
Compatibility code is ugly
It can be.
Bridges, electrical substations and sewage systems also contain details that are not aesthetically pure. Infrastructure is judged by service, not by how closely reality matches a diagram. The ugliness can be isolated at boundaries. Internals remain clean. Tests ensure the adapter does not contaminate new logic. The extra code represents encoded respect for existing users.
Deleting it makes the producer’s repository prettier by making the world messier.
Security requires everyone to upgrade
Security requires vulnerable behavior to stop. It does not automatically require unrelated interfaces to change.
Where an old contract is intrinsically unsafe, a transition must be made. The burden of proof should identify the specific danger, the least destructive correction and the longest safe overlap. Migration tooling and compatibility gateways are part of the security work, not optional customer service.
Routine breakage can itself prevent upgrades and leave vulnerable systems deployed. A trusted compatible update channel is one of the strongest security mechanisms available.
Users demand new features
Users often ask for new capability. They rarely ask for their existing workflows to stop working.
Features can be additive, optional and discoverable. Defaults can remain stable. New interfaces can coexist with old ones. If a user explicitly chooses a new workflow, that is different from forcing every user to migrate because the producer wants a uniform code path.
The request for a new room does not imply permission to demolish the house.
Hardware changes too quickly
Hardware changes are exactly why stable abstractions matter.
Instruction sets, operating-system interfaces, protocols and portable languages allow software to survive physical replacement. Mechanical standards allow new components to fit old systems. A compatibility layer converts hardware change from a global rewrite into a local implementation problem.
Without stable boundaries hardware progress would slow, because every new processor or device would begin with no usable ecosystem.
And by the way - hardware changes way slower than people suggest. The major instruction set on consumer computers is x86 and it’s in place since 1978. This is only fast on a vampires scale of time.
Legacy support prevents optimization
Sometimes an old path limits performance. The correct response is to measure where the limit matters and add a new path for users who need it.
Most users do not require every theoretical optimization. They require their system to continue working. Forcing a migration onto all users to improve a minority case is a poor global optimization. System/360, Ethernet and the web all evolved through substantial performance changes while preserving architectural continuity[18,20,13]. The engineering may be harder. The accumulated result is larger.
A startup cannot promise thirty years
A young organization cannot guarantee its own survival. It can avoid making its survival a technical prerequisite.
It can publish formats, document protocols, provide export, support local operation, release reference code and use standard components. It can design a graceful failure mode in which customers retain their data and basic capability.
Long-term engineering is not a prediction that the company will exist forever. It is a refusal to make users lose everything if it does not.
Sometimes replacement really is better
Yes. Stability is not a claim that every old system deserves infinite operation. A replacement may offer overwhelming safety, capability or efficiency benefits. The stability principle determines how the transition should be evaluated:
- count global migration cost
- preserve data
- provide adapters
- allow overlap
- avoid unrelated breakage
- make migration voluntary until continued operation creates a concrete harm
Replacement becomes responsible when it adds more retained capability than it destroys.
A Stable World Moves Further
Progress compounds only when it remains
Economic accounts of technical change and learning by doing describe growth that emerges from accumulated knowledge, improved methods and repeated production[44,45]. Accumulation is the operative word.
If every generation must repair or recreate the tools of the previous one, knowledge does not compound efficiently. Human lifetime is spent restoring the starting point. The society may look busy and still advance slowly. Stable foundations change the arithmetic. Once a problem is solved well enough, it remains solved. The next person begins above it. Their work can address a genuinely new problem rather than an avoidable incompatibility.
This is how a small amount of reliable infrastructure supports an enormous amount of visible activity.
The hierarchy of useful work
Technical work can be arranged in a rough hierarchy:
- repeated manual execution
- repair of preventable failures
- migration caused by avoidable change
- automation of repetition
- stabilization of the automated system
- creation of genuinely new capability
- consolidation of that capability into a foundation for others
Modern culture often celebrates level 6 and ignores level 7. It also mistakes levels 2 and 3 for evidence of a vibrant productive technical organization.
The highest leverage comes from completing the cycle. A new capability becomes civilizational progress only when it can be inherited.
What should move fast
Ideas may move fast inside notebooks, laboratories and private branches. Measurements should move fast through automated pipelines. Bug fixes should move fast through trusted compatible update channels. Internal implementations may move fast behind stable boundaries.
Public obligations should move slowly.
Data meanings, protocols, file formats, physical interfaces and user workflows should change only with evidence that the global benefit exceeds the global cost. The more downstream dependence an interface has attracted, the stronger this presumption should become.
This is not conservatism about goals. It is ambition about timescale.
Fifty years is not an eternity
Fifty years sounds long in a software planning meeting. It is short for a building, an instrument, a scientific field, an archive, a railway, an industrial plant or a human career.
A person beginning research today may still need the resulting data in fifty years. A control system installed today may still operate machinery then. A child creating a document today may reasonably want to read it later. A public institution has obligations longer than a venture-capital cycle.
Technology that cannot imagine fifty years is not modern. It is temporally narrow.
The final criterion
When evaluating a new system, one can ignore much of the marketing and ask one question:
Does this allow future people to build on present work, or does it require them to rebuild present work first?
The first kind of technology creates progress. The second creates motion.
Stable systems are not dead systems. They are systems whose useful past remains present while their internals and capabilities improve. They reduce human supervision, permit automation, preserve knowledge, protect physical investment and make independent work composable.
The world does not improve because everything changes. It improves because things stop breaking.
References
- Foundations, software evolution and maintenance
- [1] T. Spielauer, Automation and Stability as Foundations of Sustainable Growth
- [2] M. M. Lehman, Programs, Life Cycles, and Laws of Software Evolution, Proceedings of the IEEE, vol. 68, no. 9, pp. 1060–1076, 1980.
- [3] T. Besker, A. Martini, and J. Bosch, Software Developer Productivity Loss Due to Technical Debt - A Replication and Extension Study Examining Developers’ Development Work, Journal of Systems and Software, vol. 156, pp. 41–61, 2019.
- [4] NASA, NASA Systems Engineering Handbook, NASA/SP-2016-6105 Rev. 2, 2016.
- [5] V. Cunningham, The WyCash Portfolio Management System in Addendum to the Proceedings on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA ’92), 1992, pp. 29–30.
- [6] D. Sculley et al., Hidden Technical Debt in Machine Learning Systems, in Advances in Neural Information Processing Systems 28, 2015.
- [7] Google, Eliminating Toil, in Site Reliability Engineering: How Google Runs Production Systems, O’Reilly Media, 2016.
- [8] L. Xavier, A. Brito, A. Hora, and M. T. Valente, Historical and Impact Analysis of API Breaking Changes: A Large-Scale Study, in 2017 IEEE 24th International Conference on Software Analysis, Evolution and Reengineering (SANER), 2017, pp. 138–147.
- [9] D. Jayasuriya et al., An Extended Study of Syntactic Breaking Changes in the Wildhttps://doi.org/10.1007/s10664-024-10563-4
, Empirical Software Engineering, vol. 30, 2025.
- [10] DORA, DORA’s Software Delivery Performance Metrics, 2026.
- Long-lived computing foundations
- [11] Linux kernel project, Linux ABI Description, The Linux Kernel Documentation.
- [12] SQLite project, Long Term Support, updated 31 May 2025.
- [13] W3C HTML Working Group, HTML Design Principles, W3C Working Draft, 26 November 2007.
- [14] R. Braden, ed., Requirements for Internet Hosts—Communication Layers, RFC 1122, Internet Engineering Task Force, October 1989.
- [15] J. Postel, ed., Transmission Control Protocol, RFC 793, Internet Engineering Task Force, September 1981.
- [16] P. Mockapetris, Domain Names—Concepts and Facilities, RFC 1034, Internet Engineering Task Force, November 1987.
- [17] The Open Group and IEEE, POSIX.1-2024 / IEEE Std 1003.1-2024: Base Specifications, Issue 8, 2024.
- [18] G. M. Amdahl, G. A. Blaauw, and F. P. Brooks, Jr., Architecture of the IBM System/360, IBM Journal of Research and Development, vol. 8, no. 2, pp. 87–101, 1964.
- [19] IBM, The IBM System/360, IBM History.
- [20] IEEE Standards Association, IEEE 802.3-2022: IEEE Standard for Ethernet, 2022.
- [21] USB Implementers Forum, Universal Serial Bus 3.2 Specification, Revision 1.1, June 2022.
- [22] MIDI Association, Details about MIDI 2.0, MIDI-CI, Profiles and Property Exchange, updated June 2023.
- [23] ISO/IEC and ITU-T, Digital Compression and Coding of Continuous-Tone Still Images: Requirements and Guidelines, ISO/IEC 10918-1 / ITU-T Recommendation T.81, 1992.
- [24] ISO, ISO 32000-2:2020—Document Management—Portable Document Format—Part 2: PDF 2.0, 2020.
- Apparently sudden products built from slow foundations
- [25] Apple, Apple Reinvents the Phone with iPhone, press release, 9 January 2007.
- [26] D. E. Rumelhart, G. E. Hinton, and R. J. Williams, Learning Representations by Back-Propagating Errors, Nature, vol. 323, pp. 533–536, 1986.
- [27] A. Krizhevsky, I. Sutskever, and G. E. Hinton, ImageNet Classification with Deep Convolutional Neural Networks, in Advances in Neural Information Processing Systems 25, 2012.
- [28] A. Vaswani et al., Attention Is All You Need, in Advances in Neural Information Processing Systems 30, 2017.
- [29] Y. LeCun, Y. Bengio, and G. Hinton, Deep Learning, Nature, vol. 521, pp. 436–444, 2015.
- Scientific and technological time scales
- [30] Nobel Assembly at Karolinska Institutet, The Nobel Prize in Physiology or Medicine 2023—Advanced Information: Discoveries Concerning Nucleoside Base Modifications that Enabled the Development of Effective mRNA Vaccines Against COVID-19, 2023.
- [31] K. Karikó, M. Buckstein, H. Ni, and D. Weissman, Suppression of RNA Recognition by Toll-like Receptors: The Impact of Nucleoside Modification and the Evolutionary Origin of RNA, Immunity, vol. 23, no. 2, pp. 165–175, 2005.
- [32] Royal Swedish Academy of Sciences, The Nobel Prize in Chemistry 2019—Advanced Information: Lithium-Ion Batteries, 2019.
- [33] Royal Swedish Academy of Sciences, The Nobel Prize in Chemistry 2020—Advanced Information: A Tool for Genome Editing, 2020.
- [34] M. Jinek et al., A Programmable Dual-RNA-Guided DNA Endonuclease in Adaptive Bacterial Immunity, Science, vol. 337, no. 6096, pp. 816–821, 2012.
- [35] B. P. Abbott et al. (LIGO Scientific Collaboration and Virgo Collaboration), Observation of Gravitational Waves from a Binary Black Hole Merger, Physical Review Letters, vol. 116, 061102, 2016.
- [36] Z. S. Morris, S. Wooding, and J. Grant, The Answer Is 17 Years, What Is the Question: Understanding Time Lags in Translational Research, Journal of the Royal Society of Medicine, vol. 104, no. 12, pp. 510–520, 2011.
- Standards, infrastructure and network value
- [37] ISO, ISO 668:2020—Series 1 Freight Containers—Classification, Dimensions and Ratings, 2020.
- [38] D. M. Bernhofen, Z. El-Sahli, and R. Kneller, Estimating the Effects of the Container Revolution on World Trade, Journal of International Economics, vol. 98, pp. 36–50, 2016.
- [39] M. L. Katz and C. Shapiro, Network Externalities, Competition, and Compatibility, American Economic Review, vol. 75, no. 3, pp. 424–440, 1985.
- [40] J. Farrell and G. Saloner, Standardization, Compatibility, and Innovation, RAND Journal of Economics, vol. 16, no. 1, pp. 70–83, 1985.
- [41] LEGO Group, LEGO System in Play, LEGO History.
- [42] Bureau International des Poids et Mesures, The International System of Units (SI), 9th ed., 2019, updated 2022.
- Organization, exploration and long-term productivity
- [43] J. G. March, Exploration and Exploitation in Organizational Learning, Organization Science, vol. 2, no. 1, pp. 71–87, 1991.
- [44] R. M. Solow, Technical Change and the Aggregate Production Function, Review of Economics and Statistics, vol. 39, no. 3, pp. 312–320, 1957.
- [45] K. J. Arrow, The Economic Implications of Learning by Doing, Review of Economic Studies, vol. 29, no. 3, pp. 155–173, 1962.
]]>
