So apparently, baby painted turtles survive being frozen.

That’s the start of Patrick Dubroy’s blog post about cold-blooded software. Patrick likens software projects to warm-vs-cold-blooded animals:

• Cold-blooded: Some projects you can let sit around untouched for years without trouble. They don’t get any worse from neglect and from not working on them.
  • “A cold-blooded project uses boring technology.” (My emphasis.) – Nothing breaks by letting it sit for a while.
  • No cloud service provider that goes out of business and breaks your build, no intricate and unstable dependency tree.
  • Dependencies are ideally checked-in, so you can run everything locally.
• Warm-blooded: You need to actively work on these projects because every prolonged break worsens the state of the project. Ever tried to upgrade a stale Python 2.7 project to v3?
  • Activity / Keeping the temperature up: You can’t run cold-blooded projects as warm-blooded projects: “There’s not enough activity to keep the temperature up.”

Anecdotally, I found something like that to be painfully true with some parts of my note-taking app “The Archive”. Some core components are great when “cooled”. It’s actually nice to forget about the details and work with the public API. But some intricate procedures (and especially wonky platform workarounds) stop speaking to me after a while. In my app, that’s a sign of missed opportunities to improve the code and increase its “shelf-life”, so to speak.

(via: Jim Nielsen: “Cold-blooded Software”, 2024-01-04, https://blog.jim-nielsen.com/2024/cold-blooded-software/)