Stability Is Key: How Lasting Systems Create Real Progress

26 Jul 2026 - tsp
Last update 26 Jul 2026
Reading time 66 mins

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:

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:

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:

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:

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:

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:

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:

The foundation lane is explicitly durable:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

  1. repeated manual execution
  2. repair of preventable failures
  3. migration caused by avoidable change
  4. automation of repetition
  5. stabilization of the automated system
  6. creation of genuinely new capability
  7. 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

This article is tagged: Programming, Opinion, Basics, How stuff works, Internet, Society

Related articles

Automation and Stability as Foundations of Sustainable Growth

Automation and stability are not optimizations - they are the foundations of sustainable growth. Every task that remains manual consumes human lifetime again and again, while every task automated correctly disappears forever. Well-designed automation scales, parallelizes, and compounds over time, freeing human attention for what actually requires judgment and creativity. Yet despite overwhelming evidence, automation is still treated as a short-term cost decision rather than a long-term structural investment. Paradoxically, modern work culture often rewards the opposite of what works. Fragile systems, constant firefighting, and visible busyness are celebrated, while stable, automated infrastructure remains invisible and undervalued. This article argues, with empirical evidence and real-world examples, that progress only becomes permanent when humans are removed from unnecessary loops, stability is treated as a first-class constraint, and society learns to reward systems that quietly keep working instead of those that constantly break.

The Hum That Never Sleeps - A Vision

From the Borg and Stargates Replicators to RepRap printers, orbital shipyards, biohybrid robots and autonomous AI agents, the dream of machines that can build more machines has fascinated engineers and science-fiction writers alike. This article explores self-replication as an engineering problem rather than merely a fictional concept, comparing how different systems acquire materials, manufacture successors, share knowledge, overcome bottlenecks and ultimately sustain themselves. Along the way we revisit John von Neumanns visionary concept of the universal constructor, examine real-world projects that are already taking their first steps toward recursive manufacturing and discuss the often-overlooked foundations that make self-replication possible: feedstock, metrology, documentation, governance, and careful engineering. The result is a journey through one of technologys most ambitious ideas - from today's workshops and AI runtimes to the autonomous factories that may one day build the next generation of machines.

A short story of using QWen3.6:35b-a3b with codex

Running powerful coding agents no longer requires a data center. Modern open-weight language models can already perform surprisingly useful software development tasks on ordinary consumer hardware, making self-hosted AI an attractive alternative for developers who value privacy, offline operation or simply want to avoid constantly burning API credits. This article follows the practical journey of connecting Qwen3.6:35B-A3B to Codex through Ollama, from model tuning and configuration to the inevitable bugs, quirks and unexpected failure modes. Along the way it explains the most important sampling parameters, shows complete working configurations and offers an assessment of what todays local coding models can - and cannot - do.

What (in my opinion) one can learn from Erlang/OTP for other programming languages

Since I'm a huge fan of the Erlang programming language and the OTP toolkit but normally aren't working with projects where Erlang is suited or in case some existing code is using already other languages and so I'm not capable of using Erlang I tried to summarize some of the things that I think one can learn from programming in Erlang/OTP even when using other programming languages. Of course this stuff is not enforced by the runtime environments and it's harder to achieve on other platforms but the approaches work nevertheless.

Optimizing GLM for dual processor Westmere Xeon E5620: 200% gain (3x faster) till now

In this article I am summarizing a bunch of optimizations I performed on the colibri runtime for GLM-5.2 specifically for an Westmere Xeon E5620 dual-socket Xeon machine. It is a summary of the ideas, what worked and what did not - and it shows why some seemingly cleaver ideas were simply not worth keeping.

Coding with an AI Assistant: My Ongoing Journey into Vibe Coding

Pair programming with an AI might sound futuristic or flaky - but what if it actually works? In this short article (that evolves over time) I reflect on my personal evolving experience with vibe coding: a collaborative, conversational approach to software development using large language models. From architectural planning and boilerplate generation to debugging rituals and code reviews the article reveals how these tools can be both uncanny helpers and frustrating novices - often within the same session. This is not another contribution to the hype. Instead, you'll find some practical advice, mentions of the cost involved, tool recommendations and cautionary tales drawn from real-world projects. The article invites you to explore what it's like to co-create software with a machine that remembers nothing, hallucinates confidently, and - if you guide it well - helps you build better, faster, and with fewer headaches.

Using Codex with Hardware In The Loop for Microcontrollers

What happens when an AI does not just suggest code, but actually compiles it, flashes it onto a microcontroller, and tests it against real hardware? In this article we explore a workflow where Codex is wired directly into a ModBus RS485 test bench, turning firmware development into a continuous loop of design, implementation, and validation on real silicon. Instead of the usual edit–build–flash cycle, the system behaves more like a self-driven engineer: asking architectural questions, updating documentation, running tests, and iterating until the behavior matches the specification. Using a concrete ATmega2560 + MAX485 setup, we walk through how design documents, TODO tracking, and an explicit agent contract enable this workflow—and what it feels like to debug firmware when the assistant can probe the system itself. From catching subtle protocol violations to restructuring configuration handling in real time, the result is a development process that blends structured engineering with rapid experimentation, all with hardware permanently in the loop.

Colibri: Running a 744 Billion Parameter LLM with 20 GB of RAM on FreeBSD

Modern frontier scale large language models (LLMs) are normally associated with clusters of very expensive GPUs and hundreds of gigabytes of memory. Yet recent advances in Mixture-of-Experts architectures and intelligent inference runtimes challenge this assumption. In this short article we explore how the 744 billion parameter GLM-5.2 model can be executed on an old dual-Xeon FreeBSD workstation equipped with just 20 GB of RAM by streaming expert weights directly from NVMe storage. Beyond documenting the necessary FreeBSD port of the ColibrĂŹ runtime, the article explains the underlying memory hierarchy, Mixture-of-Experts routing, activation vector steering and practical performance characteristics of such an unconventional setup. While the resulting system is certainly no replacement for modern GPU servers, it demonstrates that frontier scale language models are becoming accessible on surprisingly modest hardware, provided one is willing to trade latency for capability.

Also on this blog

Simple 230V monitoring using PC817 opto coupler

A really simple circuit to monitor the presence of a 230V AC line using an PC817 opto coupler and a 5V or 3.3V microcontroller

Science as a Collective, Ever-Growing Enterprise

For a long time, I thought of science as something done by brilliant individuals - lonely minds uncovering truths in isolation, excelent researchers doing their isolated work far above the understanding capabilities of everyone else. Over time, I realized that this image is deeply incomplete. Science is not a solitary act but a vast collective enterprise: a self-organizing network of countless people across generations, each contributing a fragment to the immense mosaic of human knowledge. It’s not just about experiments, but about documenting, teaching, and preserving what we learn so others can build upon it. Yet this collective enterprise does not mean constant social interaction — its true communication channels are publications and presentations, the shared language of discovery. This essay explores science as a living, creative system - one that depends as much on imagination and diversity of minds as on logic and precision. It argues that politics and the public often miss this deeper truth: that the scientific process is society’s long-term memory and imagination combined, not merely a source of immediate economic gain or the work of some view excellent isolated minds that compete against each other and whos performance can be measured in form of economic gain or number of publications. From the quiet curiosity of basic research to the emerging cooperation between human thinkers and artificial intelligence, science remains our shared attempt to understand the universe - together.

Why Your Mean Is More Stable Than Your Standard Error Suggests

If you have ever taken dozens, hundreds or millions of measurements and marveled at how steady your average seems this short blog article may shed some light on the effects causing this. While naive statistics tell us the standard error should shrink with more samples, real-world measurements often don't behave so cleanly. We explore why your mean can appear surprisingly stable, even when standard deviation or error bars suggest high uncertainty, and what role correlated noise plays in this apparent contradiction. Taking a look at the limits of traditional assumptions like white noise and sample to sample independence, we take a peek how phenomena like drift and flicker noise distort common statistical tools - and when they lead you to under- or overestimate your actual uncertainty. We mention why Allan deviation is an essential tool for uncovering the true nature of your data and how blindly trusting standard error can mislead both your interpretation and reporting precision.

Running JupyterLab Behind an Apache Reverse Proxy

Want to access your internal JupyterLab instance securely over HTTPS? This quick guide shows how to set up Apache 2.4 as a reverse proxy for JupyterLab 4.2.5, with working websocket support and proper configuration on both ends. Learn how to avoid common pitfalls like broken kernels or missing output—and get your lab running smoothly behind your own public facing reverse proxy

Data protection policy

Dipl.-Ing. Thomas Spielauer, Wien (webcomplainsQu98equt9ewh@tspi.at)

This webpage is also available via TOR at http://rh6v563nt2dnxd5h2vhhqkudmyvjaevgiv77c62xflas52d5omtkxuid.onion/

Valid HTML 4.01 Strict Powered by FreeBSD IPv6 support