🍄Cold Blooded Software

Certain technology decisions lead to projects that are warm-blooded: everything is great when there’s constant motion on the project, generating heat. But put warm-blooded software in the freezer, and you’ll pull out a corpse six months later.

Maybe your CI isn’t working because one of the services you depend on got bought or ran out of money. You add a new dependency and find yourself needing to upgrade your compiler. Another package you depend on is deprecated, and doesn’t work with the latest version of the compiler.

Some projects are different. You work alone, make some changes when you’re inspired, and then don’t touch it again for another year, or two, or three. You can’t run something like that as a warm-blooded project. There’s not enough activity to keep the temperature up. [...]

A cold-blooded project uses boring technology. The build and test scripts don’t depend on external services that might change, break, or disappear entirely. It uses vendored dependencies.

Cold-blooded software is a nice analogy illustrating software projects which are resilient to the passage of time and which don't require much ongoing maintenance. Broadly speaking it falls under the umbrella of permacomputing.

I would extend the article's thesis somewhat and suggest that software projects designed for cold-bloodedness need to be resilient against sources of both internal entropy and external entropy. External sources have received a lot more attention than internal sources, and for good reason: they are easier to understand, control, and mitigate. Internal sources of entropy tend to be social in nature and thus harder to apply cookiecutter solutions to.

Internal Entropy, i.e. changes originating from within the software project itself

  • Design drift

  • Loss of tacit system knowledge

  • Loss of domain knowledge

  • Intra-team conflict

  • Poor practices such as not using version control, neglecting test suites, undocumented build/test/deploy procedures

  • Configuration differences among team members

  • Non-hermetic, non-reproducible builds

External Entropy, i.e. changes originating from the environment housing the software project

  • Dependency updates or disappearances

  • Deployment environment changes

  • Direct toolchain updates; e.g. compiler and language changes

  • Auxiliary system shifts; e.g. CI system, forge, artifact store, automation platform

  • Licensing or business model changes on third party tools or libraries

  • Link rot or loss of knowledge sources external to the project

Most software built on commercial foundations is subject to a high degree of both of these sources of entropy, and without constant efforts to mitigate it will collapse. Open source software tends to be a bit better, primarily because of the open nature of the work and the lack of commercial pressure to change the system. However, it's still quite common for open source projects to fail to take adequate precautions.