Tweeting for 10,000 Years: An Experiment in Autonomous Software

A Clock and a Tweet

Inside a mountain in Texas, a clock is being built with an ambition that dwarfs most human engineering: it is designed to keep time for 10,000 years. The Clock of the Long Now, a project of the Long Now Foundation, is built with components sized for the ages—a 500-foot shaft houses a 10,000-pound counterweight, and 20 gears, each 8 feet in diameter, control its chimes. A 6-foot pendulum assembly swings once every ten seconds, and parts are machined to tolerances measured in fractions of an inch rather than thousandths, so the mechanism can endure the slow creep of rust and expansion. The foundation’s calendar writes the year as 02018, a reminder that their scale spans centuries and millennia.

This ethos stands in stark contrast to the world of software, where products often have functional lifetimes measured in months and where complexity tends to accumulate until systems collapse under their own weight. But software has a unique advantage over mechanics: it isn’t tied to a single physical host. A well-designed program can migrate across hardware as infrastructure decays, relying on human maintainers to keep its platform alive.

An Experiment in Longevity

Inspired by the clock, an experiment called Perpetual was built with a deceptively simple task: post ten pre-configured tweets to a timeline on an approximately exponential schedule, with the final message optimistically set to fire 10,000 years in the future. The first tweet went out minutes after publication. Each post is prefixed with a magic string and number like LHI001 (short for "long heartbeat interval"), making scheduled tweets recognizable and allowing the program to locate the last one it published.

The logic for checking old intervals and deciding whether to post a new one is minimal, a deliberate choice aimed at reducing points of failure.

func Update(api TwitterAPI, intervals []*Interval, now time.Time)
        (int, error) {

    it := api.ListTweets()

    for it.Next() {
        lastTweet = it.Value()

        id, ok = extractIntervalID(lastTweet.Message)
        if ok {
            break
        }
    }

    if it.Err() != nil {
        return -1, it.Err()
    }

    var nextIntervalID int
    if ok {
        // Pick the next interval in the series
        nextIntervalID = id + 1
    } else {
        // If ok is false, we never extracted an interval ID, which
        // means that this program has never posted before. Pick the
        // first interval ID in the series.
        nextIntervalID = 0
    }

    if nextIntervalID >= len(intervals) {
        return -1, nil
    }

    interval := intervals[nextIntervalID]

    if interval.Target.After(now) {
        fmt.Printf("Interval not ready, target: %v\n", interval.Target)
        return -1, nil
    }

    tweet, err := api.PostTweet(
        formatInterval(nextIntervalID, interval.Message))
    if err != nil {
        return -1, err
    }

    return nextIntervalID, nil
}

The Problem of Deep Time

The program will almost certainly fail long before its 10,000-year mission is complete; 10 years would be a stretch, and 100 years would be extraordinary. Humans struggle to grasp escalating orders of magnitude, a bias known as scope insensitivity. We can calculate that there are 1,000 ten-year spans in 10,000 years, but the difference between a thousand, a million, and ten million years feels abstract. Context helps: the Pyramid of Djoser at Saqqara, the oldest pyramid, isn’t yet 5,000 years old. Cleopatra, who lived closer to the moon landing than to the building of that pyramid, looked up at monuments that were already ancient in her day. For the experiment, however, improving the odds is the goal, even if success remains unlikely.

Designing for Survival

Perpetual is engineered with several features to resist the decaying forces of time:

• A serverless architecture on AWS Lambda, insulating it from individual server failures and benefiting from Amazon's history of not retiring products and rarely making breaking changes.
• No persistent state. The program relies entirely on state returned from Twitter's API, avoiding the operational problems that plague databases.
• Very few moving parts, kept in the spirit of production minimalism, with only the program, Twitter's API, and the serverless platform involved.
• Written in Go, a statically typed language with a remarkable record of backwards compatibility. Even if Go 2 is released, code written against the 1.x series stands a good chance of working.
• Comprehensive tests, since static typing reduces the class of runtime errors common in interpreted languages.
• Compilation to a self-contained binary, protecting it against breakage from changes in bootstraps or dependencies.

The Likely Causes of Death

Over a timeline like this, an existential threat is not a question of if, but which one. Among the candidates:

• Application bugs, the most common software failure, which testing may mitigate but never eliminate.
• Twitter API changes, such as a backwards-incompatible modification requiring new parameters, changing response structures, or altering authentication methods.
• Twitter product changes, including new pricing models, core design overhauls, or the company's collapse.
• AWS risks, such as changes to the minimal API that Go Lambda functions use, product retirement, or loss of the free-tier account footing.
• Binary compatibility, where the compiled program eventually becomes incompatible with low-level operating system APIs and requires recompilation with a newer Go toolchain.

The most likely culpri, is a change to Twitter's API. It has been stable for some time but has accumulated rough edges, and a major revitalization project could spell the end of the current API after a deprecation period lasting at most a few years.

Lessons from the Long Now

The Long Now Foundation devised a set of guiding principles for the clock, which they describe as "generally good for designing anything to last a long time." They are:

• Longevity: The clock must be accurate after 10,000 years and contain nothing valuable enough to be looted.
• Maintainability: Future generations should be able to service it with Bronze Age tools.
• Transparency: Its operation should be understandable without disassembly.
• Evolvability: It should be possible to improve it over time.
• Scalability: Working models from table-top to monumental size should use the same design.

Rethought for software, these become a practical checklist for building systems that are likely to outlive their creators' tenure:

• Longevity means writing robust code that handles edge cases, is well-tested, favors static typing, and avoids brittle dependencies.
• Maintainability calls for frameworks that future developers can pick up with minimal toolchains and documentation that has proven stable.
• Transparency pushes for clear, elegant code where abstractions aid understanding rather than obscure it.
• Evolvability means future developers should be able to improve the system safely, aided by a good compiler and test suite.
• Scalability ensures that production software is validated with extensive tests and high-fidelity pre-production environments.

Software often remains in operation far longer than its authors expect, and the entropy of its ecosystem can take its toll sooner than imagined. These principles are useful well before any 10,000-year horizon arrives.

What went wrong

April 14, 2023: entropy won. The experiment ran for 4 years, 8 months. Less than the stated goal, though not a bad run.

Twitter's notice was brief: the app "10000-years" has been suspended from API access. The free tier that allowed it to run is being retired for most applications. A free account still exists for write-only operations, but the bot's logic requires read access to verify it doesn't double-post. And updating the code to work around this would violate the experiment's intent from the start.

The fundamental issue: writing software that lasts is not a solved problem.

This is a notice that your app - 10000-years - has been suspended from accessing the Twitter API.

Please visit developer.twitter.com to sign up to our new Free, Basic or Enterprise access tiers.