Jim Nielsen’s Blog Verified ($10/year for the domain)
Preferences
Theme: This feature requires JavaScript as well as the default site fidelity (see below).
Fidelity:

Controls the level of style and functionality of the site, a lower fidelity meaning less bandwidth, battery, and CPU usage. Learn more.

Cold-blooded Software

Patrick Duboy has an interesting post making the rounds titled, “Cold-blooded Software”.

He analogizes the idea of warm-blooded software:

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.

Against cold-blooded software:

[Other] 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.

[With] A cold-blooded project…You can freeze it for a year and then pick it back up right where you left off.

I like both warm-blooded and cold-blooded. Both have their benefits and drawbacks. Context, as ever, is key.

Biology is not my strong suit, but I’m sure you could spend a lot of time contrasting the trade-offs of being a warm-blooded vs. a cold-blooded animal in nature.

A cold-blooded animal relies on its environment to regulate its body temperature. You rely on what’s provided by your external environment or you die.

Similarly, cold-blooded software lives off what its platform supplies natively — in the case of the web, that’s vanilla HTML, CSS, and JS.

A warm-blooded animal, in contrast, has flexibility. It can regulate its own body temperature allowing it to go above and beyond what its immediate environment offers. However, this comes at a cost: a lot of energy must be expended keeping its body at a consistent temperature.

Similarly, warm-blooded software is not wholly dependent on what the platform supplies. It can make its own way — in the case of the web, that means languages, build tools, and whatever else you can dream of that is above and beyond what the platform offers natively. But there’s a cost in energy, and if you can’t continually pay that cost — well, you die.

I like how datarama on lobster.rs put it:

One of [cold-blooded’s] most important benefits over [warm-blooded’s] is that they can have extremely low energy needs…

“Cold-blooded software” would, I think, be software that tolerates the world around it changing because it’s adapted to have very modest needs that don’t get invalidated easily. But just like there are barely any reptiles in the Arctic, there are going to be parts of our software ecosystem that will be less hospitable to “cold-bloodedness”.

So pick the context that’s right for you and your project. There’s no universal right or wrong, just trade-offs.

As for me and my personal projects, I’ve lived long enough to say: give me cold-blooded web pages or give me death.

But seriously, I will die inside if I have to re-open that webpack project from 2015.