[1] Jim Nielsen’s Blog Verified ($10/year for the domain) [2]Archive [3]About 
[4]RSS 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. [5]Learn more.

[6](*) Default [7]( ) Minimal [8]( ) Text-Only Update
Cold-blooded Software

2024-01-04

Patrick Duboy has an interesting post making the rounds titled, [10]
“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 [11]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.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Comment? Reply via: [12]Email, [13]Mastodon, or [14]Twitter.



References:

[1] https://blog.jim-nielsen.com/
[2] https://blog.jim-nielsen.com/archive/
[3] https://blog.jim-nielsen.com/about/
[4] https://blog.jim-nielsen.com/feed
[5] https://blog.jim-nielsen.com/2022/website-fidelity/
[10] https://dubroy.com/blog/cold-blooded-software/
[11] https://lobste.rs/s/hitos3/cold_blooded_software#c_mxjzwh
[12] mailto:jimniels%2Bblog@gmail.com?subject=Re:%20blog.jim-nielsen.com/2024/cold-blooded-software/
[13] https://mastodon.social/@jimniels
[14] https://twitter.com/jimniels
