Cold-blooded software

Original Article ↗ Hacker News Discussion ↗

Software that can be “frozen” for years and restarted without breakage — so‑called cold‑blooded software — appeals to developers tired of constant dependency and framework churn. Commenters explore when this is realistic, contrasting long‑lived C, Go, Java, PHP or static HTML apps with fragile mobile, Python, Node and frontend toolchains that often break under new OSes, SDKs or package versions. Many see strict dependency control, stable platforms, and simple architectures as the only way to get decades-long longevity, but note that security updates, changing business needs, and fast‑moving ecosystems often force warmer, continuously maintained systems.

Longevity vs Ephemeral Software

  • Many agree some software should be built to last decades (utilities, infrastructure, blogs, CMSes), but others note many apps are inherently short‑lived as use cases and tech stacks evolve.
  • Some argue rewrites can become cheaper than maintaining decades‑old systems; others strongly dispute this, citing huge costs and risks of touching old but critical systems.
  • The “Buxton Index” / time horizon idea is used to explain differences: some people/organizations plan for years; others optimize for the next quarter.

Security, Ecosystem Churn, and Maintenance Burden

  • A recurring objection: in a live, networked, or regulated environment, security updates and ecosystem changes force ongoing maintenance, making true “cold‑blooded” software rare.
  • Examples of painful churn: mobile apps (iOS/Android SDK changes, app store policies), Xcode updates breaking old projects, package ecosystem breakage (Node, Python, front‑end builds).
  • Some counter that careful planning (LTS OS releases, no network, limited surface area) can keep systems viable and low‑touch for many years.

Dependencies, Tooling, and Strategies for Stability

  • Strong emphasis on minimizing dependencies, especially build tools and fast‑moving frameworks; many prefer static binaries, vendoring, containers, or even frozen VMs.
  • Several describe success with simple stacks: C, PHP, Go, Java, Perl, Elixir, vanilla JS, and Unix tools like Make/Pandoc.
  • Others highlight that containers and distroless images can “freeze” environments, but only shift where maintenance happens, not eliminate it.

Language, Framework, and Platform Experiences

  • Praised for stability/backwards compatibility: Go (with modules and compatibility promise), Java (with caveats after Java 9), Perl, C, some PHP, Express.js, Elixir/Erlang libraries, IBM mainframe, Windows, Linux kernel.
  • Criticized as “warm‑blooded”: Python (2→3 split, frequent deprecations, dependency tooling), modern JS build stacks, some Ruby and Node ecosystems.
  • There’s debate: some report Python running unchanged for many years with disciplined tooling; others experience constant breakage.

Library Freshness and “Done” Software

  • Checking “last commit” is seen as a useful but imperfect heuristic: often means abandonment, but some libraries are genuinely finished and stable for years.
  • Concerns: unmaintained libraries can hide security issues and incompatibilities; but stable, tiny, dependency‑free libraries can remain useful indefinitely.

Philosophical Takes and Metaphor Critique

  • Several embrace “yesterday’s technology tomorrow” and boring tools to maximize predictability.
  • Others criticize the “cold‑blooded” biological metaphor as inaccurate or confusing, preferring plainer concepts like “few external dependencies” and clear threat models.