32 ms·

Cold-blooded software

558 points by arbesman 3y ago

armchairhacker 3y ago
Counterpoint: some types of software aren’t meant to last long. Even if it still builds and can be worked on later, the usecase itself may have changed or disappeared, or someone has probably come up with a new better version, so that it’s no longer worth it to continue. This probably doesn’t apply to many types of software over 6 months, but in a couple years or a couple decades. Some online services like CI or package managers will almost certainly provide backwards-compatible service until then. Another possibility is that developer efficiency improves so much that the code written 10 years ago is easier to completely rewrite today, than it is to maintain and extend. This is why I’m hesitant to think about software lasting decades, because tech changes so fast it’s hard to know what the next decade will look like. My hope is that in a few years, LLMs and/or better developer tools will make code more flexible, so that it’s very easy to upgrade legacy code and fix imperfect code.
- iamthepieman 3y ago
  "Another possibility is that developer efficiency improves so much that the code written 10 years ago is easier to completely rewrite today, than it is to maintain and extend." This seems completely false to me and I'm curious what has caused you to believe this as I'm a fairly imaginative and creative person yet I cannot imagine a set of circumstance that would lead someone to this conclusion. In other words, I disagree so very strongly with that statement that I wanted to engage rather than just downvote. (I didn't btw). I agree with your first statement though and I don't think the op is saying only make cold-blooded projects.
  - dartos 3y ago
    Well. I don’t know if I agree or not, but felt like playing devils advocate. take the example of game development. Trying to maintain, say, the hobbit game from the early 2000s to today would almost certainly take more work than just making a new one from scratch today (GPUs have changed drastically over the past 20 years and making simple 3d platformers with unreal is so easy, “asset flips” are a new kind of scam) Or a tool which lets people visually communicate over vast distances without specialized hardware. That was a huge lift in the 2000s when Skype was the only major player, but you can find tutorials for it now using webrtc.
languagehacker 3y ago
Cold-blooded software seems like a great idea in spaces where the security risk and business impact are low. I can think of a lot of great hobbyist uses for this approach, like a handmade appliance with Arduino or Raspberry Pi. The ever-evolving threat landscape at both the OS and application level makes this unviable for projects with any amount of money or sensitivity behind them. Imagine needing to handle an OS-level update and learning that you can no longer run Python 2 on the box you're running that project on. Fine for a blog, but calamitous for anything that handles financial transactions.
- kardianos 3y ago
  If you are a bank, a store, or handle PHI, you will have contractual obligations to maintain it. However, I still think that can be "cold-blooded" maintenance. When I update a Go project after running `govulncheck ./...`, it is generally easy. I vendor; builds and runtime only rely on systems I control.
  - apantel 3y ago
    Many large companies and business like banks and manufacturers run legacy code in ancient runtimes. The projects can be so frozen in time that nobody has the courage to touch them.
- joshuaissac 3y ago
  > Cold-blooded software seems like a great idea in spaces where the security risk and business impact are low. I can think of a lot of great hobbyist uses for this approach, like a handmade appliance with Arduino or Raspberry Pi. I think it would be the other way around. A low-impact hobby project can use exciting, fast-moving technology because if it breaks, there is not so much damage (move fast and break things). But something with high business impact should use boring, tried-and-tested technologies no external network dependencies (e.g. a package being available in a third-party repository at compile time or runtime). For something like that, the OS updates (on the LTS branch if Linux) would be planned well ahead, and there would be no surprises like the Python 2 interpreter suddenly breaking.
- 3y ago
082349872349872 3y ago
I suspect our differences in preferences for cold- vs warm-blooded projects may be related to the "Buxton Index" as mentioned in https://www.cs.utexas.edu/users/EWD/transcriptions/EWD11xx/EWD1175.html https://www.cs.utexas.edu/users/EWD/transcriptions/EWD11xx/E...
- chrisweekly 3y ago
  Curious, I read the linked transcript to find: "My third remark introduces you to the Buxton Index, so named after its inventor, Professor John Buxton, at the time at Warwick University. The Buxton Index of an entity, i.e. person or organization, is defined as the length of the period, measured in years, over which the entity makes its plans. For the little grocery shop around the corner it is about 1/2,for the true Christian it is infinity, and for most other entities it is in between: about 4 for the average politician who aims at his re-election, slightly more for most industries, but much less for the managers who have to write quarterly reports. The Buxton Index is an important concept because close co-operation between entities with very different Buxton Indices invariably fails and leads to moral complaints about the partner. The party with the smaller Buxton Index is accused of being superficial and short-sighted, while the party with the larger Buxton Index is accused of neglect of duty, of backing out of its responsibility, of freewheeling, etc.. In addition, each party accuses the other one of being stupid. The great advantage of the Buxton Index is that, as a simple numerical notion, it is morally neutral and lifts the difference above the plane of moral concerns. The Buxton Index is important to bear in mind when considering academic/industrial co-operation."
  - salawat 3y ago
    Holy shit. I am so using this as a communication clarifying tool. Nice concept.
  - apantel 3y ago
    Great concept, but isn’t it just “time horizon”? Everyone knows “time horizon”.
    - 3y ago
jollyllama 3y ago
This is why I am trying to switch as many projects I'm on as possible to HTMX. The churn involved with all of the frontend frameworks means that there's far too much update work needed after letting a project sit for N quarters.
- mikewarot 3y ago
  I googled HTMX, all excited that maybe, just maybe, the browser people got their shit together and came up with a framework we can all live with, something native to the browser with a few new tags, and no other batteries required.... and was disappointed to find it's just a pile of other libraries 8(
  - dartos 3y ago
    Everything is a pile of libraries. It’s a pile of someone else’s code all the way down.
    - diggan 3y ago
      You can also use the web platform straight up without transpilation, build tools, post-css compilation and all that jazz. Just vanilla JavaScript, CSS, HTML, some sprinkles of WebComponents. And you can be pretty sure that you won't have to update that for a decade or more, as compatibility won't be broken in browsers. Heck, I have vanilla JS projects I wrote 15 years ago that still render and work exactly like how they rendered/worked when I wrote them.
      - jollyllama 3y ago
        Indeed, that baggage is all that I avoid by using HTMX.
        diggan 3y ago
        You do you. It's worth knowing though that using HTMX is not vanilla JS/HTML/CSS, it's literally the opposite of that.
ryanar 3y ago
I really appreciate this idea after rewriting my blog engine three times because the frameworks I was using (Next, Remix) had fundamental changes after a year and I was multiple major versions behind. Though it depends on what you are after. If the goal is to be able to blog, time spent upgrading and rewriting code because the framework is evolving is wasted time unless you want to stay up to date with that framework. Think about how we view physical goods today, they aren’t built to last. In certain situations, like a personal blog, you want reliable software that works for years without the need to change. It also helps to have software that uses common data formats that are exportable to another system, like a blog based in markdown files, rather than JSX.
layer8 3y ago
I’m glad this isn’t about ruthless software.
- jujube3 3y ago
  Look at that subtle off-white colouring of the project landing page. The tasteful thickness of it. Oh my God, it even has a watermark!
vrnvu 3y ago
one thing I’ve noticed is that many engineers, when they’re looking for a library on Github, they check the last commit time. They think that the more recent the last commit is, the better supported the library is. But what about an archived project that does exactly what you need it to do, has 0 bugs, and has been stable for years? That’s like finding a hidden gem in a thrift store! Most engineers I see nowadays will automatically discard a library that is not "constantly" updated... Implying it's a good thing :)
- pmichaud 3y ago
  Even though it’s not strictly true, checking for recent updates is an excellent heuristic. I don’t know the real numbers, but I feel confident that in the overwhelming majority of cases, no recent activity means “abandoned”, not “complete and bug free”.
- scruple 3y ago
  I'm generally doing that to check for version compatibility across a much broader spectrum than the level of a single library.
- fabian2k 3y ago
  A library can only stay static if the environment it's used in is also static. And many of the environments in which modern software is developed are anything but static, web frontends are one example where things change quite often. A library that can stand entirely on its own might be fine if it's never updated. But e.g. a library that depends on a web frontend framework will cause trouble if it is not updated to adapt to changes in the ecosystem.
  - adonovan 3y ago
    Also, even a very stable project that is "done" will receive a trickle of minor tweak PRs (often docs, tests, and cleanups) proportional to the number of its users, so the rate of change never falls to zero until the code stops being useful.
    - 3y ago
kageiit 3y ago
For many use cases, cold-blooded software is not viable. We need better tools to automate and remove the tedium involved in upgrading dependencies or modernizing codebases to protect against ever evolving threats and adapt to changes in the ecosystem
tlhunter 3y ago
I love the sentiment of this post. I absolutely hate that my recent mobile apps from only a couple years ago l now require a dozen hours to patch them up and submit updates. The author's final point is interesting wherein they refer to their own static site generator as being cold-blooded and that it runs on Python 2. Python 2 is getting harder to install recently and will eventually make it a warm blooded project.
- ryandrake 3y ago
  I have a little hobby project (iOS and macOS) that I don't regularly develop anymore, but I use it quite often as a user, and I like to keep it compiling and running on the latest OSes. It's aggravating (and should be totally unacceptable) that every time I upgrade Xcode, I have a few odds and ends that need to be fixed in order for the project to compile cleanly and work. My recent git history comments are all variations of "Get project working on latest Xcode". I could almost understand if these underlying SDK and OS changes had to be made due to security threats, but that's almost never the case. It's just stupid things like deprecating this API and adding that warning by default and "oh, now you need to use this framework instead of that one". Platforms and frameworks need to stop deliberately being moving targets, especially operating systems that are now very stable and reliable. I should be able to pull a 10 year old project out of the freezer and have it compile cleanly and run just as it ran 10 years ago. These OS vendors are trillion dollar companies. I don't want to hear excuses about boo hoo how much engineering effort backward compatibility is.
  - dartos 3y ago
    Hardware changes over 10 years. Macs don’t even run on the same CPU architecture or support OpenGL. Sometimes things just need to change.
    - beambot 3y ago
      The worst is when your virtualization environments intended to provide long-term support don't even accomodate the "new" mainline hardware. Most frustrating example: Virtualbox doesn't work on Apple M1 or M2 chipsets.
sowbug 3y ago
A link to this article would be an effective curt reply to the "is this project dead?" GitHub issues that have been known to enrage and discourage cold-blooded project owners.
- bee_rider 3y ago
  I wonder if GitHub is a bad fit for cold blooded projects? It has social media elements, I’d expect lots of extra chatter and “engagement.”
coreyp_1 3y ago
This. This, so very much! I built my websites on Drupal 7 and have enjoyed a decade of stability. Now, with D7 approaching EOL in 1 year, I'm looking for a solution that will last another decade. There's no reason for the EOL, either, other than people wanting to force everyone to move on to a newer version. It undoubtedly means more business for some people, as they will be able to reach out to their clients and say, "Your website is about to be a security risk, so you have to pay to update it!" Unfortunately, it means more work for me to support my personal projects. And why? Because someone somewhere has decided that I should move on to something newer and more exciting. But I don't want new and exciting... I want rock solid! I'm on vacation this week. Am I learning a new hot language like Rust, Zig, Go, etc.? Nope. I have no desire to. I don't trust them to be the same in a decade, anyway. I'm focusing on C. It's far more enjoyable, and it's stable.
- dartos 3y ago
  Enjoyable is subjective. I can’t think of anything less enjoyable than hunting for segfaults in C. I’d call Go pretty rock solid at this point. Modern go vs decade old go isn’t very different. Maybe just the packages tools had 1 major changed. You’d get the same thing in C if your hardware significantly changes in the 10 years too.
  - coreyp_1 3y ago
    Haha... I agree about it being subjective! I find that I enjoy the process as much as the result. It's like bringing order to a chaotic universe. :) The thing is, I don't have many segfaults in C, and I find C much easier to debug and hunt down issues in than even C++ (which I also enjoy). Also, because C uses very little "magic", and I also know exactly what I'm getting with my code, I find it much easier to reason about. I heard a quote the other day while watching a presentation "When you're young you want results, when you're old you want control." I think I'm on the old side now. As for Go, I genuinely don't have anything against it, but I don't see why I need it either. I don't doubt that others have stellar use cases and impressive results with Go, and that's fine, too, but I don't sense any lack which prompts me to investigate further. I would love to learn more about it, but most of what I see online is either over-the-top (and therefore vomit-inducing) fanboyism, or otherwise unspectacular, which makes me ask "why bother?"
hiAndrewQuinn 3y ago
Most of the software I write is at least somewhat cold-blooded by this definition. My program to find the dictionary forms of Finnish words is an okay example: https://github.com/hiAndrewQuinn/finstem https://github.com/hiAndrewQuinn/finstem I wrote the initial draft in an afternoon almost a year ago, and from then on endeavored to only make changes which I know play nicely with my local software ecology. I usually have `fzf` installed, so an interactive mode comes as a shell script. I usually have `csvkit`, `jq`, and if all else fails `awk` installed, so my last major update was to include flags for CSV, JSON, and TSV output respectively. Etc, etc. The build instructions intentionally eschew anything like Poetry and just gives you the shell commands I would run on a fresh Ubuntu VirtualBox VM. I hand test it every couple of months in this environment. If the need to Dockerize it ever arose I'm sure it would be straightforward, in part because the shell commands themselves are straightforward. I don't call it a great example because the CLI library I use could potentially change. Still, I've endeavored to stick to only relatively mature offerings.
csdvrx 3y ago
I follow a similar approach but maybe more extreme : whenever possible, I use "YESTERDAY'S TECHNOLOGY TOMORROW" It's nicely presented on http://itre.cis.upenn.edu/~myl/languagelog/archives/000606.html http://itre.cis.upenn.edu/~myl/languagelog/archives/000606.h... > I want yesterday's technology tomorrow. I want old things that have stood the test of time and are designed to last so that I will still be able to use them tomorrow. I don't want tomorrow's untested and bug-ridden ideas for fancy new junk made available today because although they're not ready for prime time the company has to hustle them out because it's been six months since the last big new product announcement. Call me old-fashioned, but I want stuff that works. The same thing is true with free software: I prefer to use the terminal. In the terminal, I prefer to run bash and vim, not zsh and neovim. When I write code, I've found C (and perl!) to be preferable, because "You can freeze it for a year and then pick it back up right where you left off." There are rare exceptions, when what's new is so much better than the previous solution (ex: Wayland) that it makes sense to move. However, that should be rare, and you should be very sure. If you think you made the wrong choice, you can always move back to your previous choice: after playing with ZFS for a few years, I'm moving some volumes back to NTFS. Someone mentions how the author choice (python2) is getting harder to install. Cold blooded software works best when done with multiplatform standards, so I'd suggest the author does the bare minimum amount of fixes necessary to run with https://cosmo.zip/pub/cosmos/bin/python https://cosmo.zip/pub/cosmos/bin/python and call it a day. With self-contained APEs and the eventual emulator when say 20 years from now we move to Risc V, you don't have to bother about dependencies, updates or other form of breakage: compile once in a APE form (statically linked for Windows/Linux/BSD/MacOS) it will run forever by piggybacking on the popularity of the once-popular platform. Wine lets you run Windows 95 binaries about 30 years layer: I'd bet than Wine + the Windows part of the APE will keep running long after the kernel break the ABI.
slaymaker1907 3y ago
Besides what is stated in the article, it is also important to have an inherently secure threat model. For example, full websites are inherently warm-blooded since you are constantly dealing with attackers, spam bots, etc. However, static pages like Tiddlywiki are a lot better since you can avoid putting it on the web at all and browsers are incredibly stable platforms.
ganzuul 3y ago
https://en.wikipedia.org/wiki/Unix_philosophy https://en.wikipedia.org/wiki/Unix_philosophy Seems related. Tools built like this which still need constant updating must have a foundation of sand.
imran-iq 3y ago
Python is a really bad example of cold blooded software. There is constant breaking changes with it (both runtime and tooling). So much so that the author still has to use python2 which has been EOL'd for quite a while. A much better example would be something like go or java where 10 year old code still runs fine with their modern tooling. Or an even better example, perl, where 30 year old code still runs fine to this day
- 082349872349872 3y ago
  2 and 3 don't really differ that much; true cold-blooded software doesn't care which it's being run with.
- JohnFen 3y ago
  Agreed. This is one of the reasons why I avoid using Python whenever possible. Python code I write today is unlikely to be functional years from now, and I consider that a pretty huge problem.
  - heurist 3y ago
    This really depends on your environment. I've been running legacy Python servers continuously for 4+ years without breaking them or extensively modifying them because I invested in the environment and tooling around it (which I would do for any app I deploy). I can't say I want to bring all of them entirely up to date with dependencies, but they're still perfectly functional. Python is pretty great, honestly. I rarely need to venture into anything else (for the kind of work I do).
    - JohnFen 3y ago
      > I've been running legacy Python servers continuously for 4+ years That seems like a large amount of effort to make up for a large language deficiency. My (heartfelt) kudos to you! I might have been willing to do the same if I used Python heavily (I don't because there are a number of other things that makes it very much "not for me") -- but it would still represent effort that shouldn't need to be engaged in.
iqandjoke 3y ago
How about security?
aranchelk 3y ago
In my mind this is a lot more about tooling and platform than language, library, architecture, etc. I have a project that’s quite complicated and built on fast-moving tech, but with every element of the build locked down and committed in SCM: Dockerfiles, package sets, etc. Alternatively, one of my older projects uses very stable slow-moving tech. I never took the time to containerize and codify the dependencies. It runs as an appliance and is such a mess that it’s cheaper to buy duplicates of the original machine that it ran on and clone the old hard drive rather than do fresh installs.
blastbking 3y ago
I had this experience making an iOS game. After a few years of making the game, I went back to it, and found that I was unable to get it to compile. I guess iOS games are very warm blooded. Perhaps if I had stuck with a desktop platform or web it would have remained fine? Not entirely sure.
- yellow_lead 3y ago
  Mobile in general is this way. For instance, on Android, if your app isn't targeting a high enough sdk version, Google will remove it after some time. If you have to upgrade your target sdk, you may find many libraries are broken (or not supported), and it also can lead to other cascades of upgrades, like having to upgrade gradle or the NDK if you use it.
petercooper 3y ago
I think Go's backward compatibility promise – https://go.dev/blog/compat https://go.dev/blog/compat – would make much Go software 'cold blooded' by this definition (so long as you vendor dependencies!)
aeternum 3y ago
What a terrible name for this. Cold blooded animals are highly dependent on their environment whereas the body of warm-blooded animals eliminate the dependency on external temperature via metabolism. In any case, it's unnecessarily ambiguous. Why not simply say 'software without external dependencies' and eliminate the paragraphs of meandering explanation?
- littleroot 3y ago
  This is literally the only reply that hit the core of the article's problem and of course no one on this site upvoted it lol. The only thing I dislike more than software development posts that use inappropriate analogy from nature to shallowly jump to conclusion, is software development posts that use inappropriate analogy from nature to shallowly jump to conclusion with absolutely flawed understanding of the supposedly analogous natural phenomenon. And of course, painted turtles (among a few other species) can survive being frozen not because of their cold-bloodedness, but thanks to special antifreeze protein they have. Other lizards (and cold blooded animals for that matter) would just rupture their own tissues upon thawing.
- aebtebeten 3y ago
  Here's someone who was more charitable with their biological interpretation: https://lobste.rs/s/hitos3/cold_blooded_software#c_mxjzwh https://lobste.rs/s/hitos3/cold_blooded_software#c_mxjzwh
kugelblitz 3y ago
I've been maintaining my own side project. It started 12-13 years ago, with vanilla php, later rewritten with Laravel, later rewritten again with Symfony in 2017-ish. Since then I've had phases from 6-18 months where I had a total of 2-3 tiny commits (I was working full time as a freelancer, so I didn't have energy to work on my side project). But then when I had time, I would focus on it, add features, upgrade and just experiment and learn. This was super valuable to me to learn how to maintain projects long-term: Update dependencies, remove stuff you don't need, check for security updates, find chances to simplify (e.g. from Vagrant to Docker... or from Vue + Axios + Webpack + other stuff to Htmx). And what to avoid... for me it was to avoid freshly developed dependencies, microservices, complexified infrastructure such as Kubernetes. And now I just developed a bunch of features, upgraded to PHP 8.2 and Symfony 7 (released a month ago), integrated some ChatGPT-based features and can hopefully relax for 1-3 years if I wanted to. In the last 4-5 years the project has made about the same revenue as an average freelance year's revenue, so it's not some dormant unknown side project.
- Aeolun 3y ago
  I think PHP, as horrible as it feels to go back, is one example of something that’s truly backwards compatible even to its own detriment. Haven’t worked with it for years, went back to find that the horrible image manipulation functions are still the same mess that I left behind 8 years ago.
  - kugelblitz 3y ago
    Yeah, some things are still a mess, but many things I use constantly have improved so much. Here is an excerpt of a function that shows many of the updates that I use regularly: #[AsMessageHandler] readonly class JobEditedHandler { public function __construct( private Environment $twig, private EmailService $mailer, private string $vatRate, ) {} public function __invoke(JobEdited $jobEdited): void { $this->sendNotificationToJobPublisher($jobEdited); } You have attributes, much better type-hinting, constructor property promotion, read-only properties / classes. Additionally you have native Enums, named arguments and also smaller things such as match expressions (instead of case switch), array spread operator, null coalescing assignment operator, etc, etc. Especially in a CRUD-heavy setting like mine (I run a niche jobboard) it reduces so much boilerplate and increases type-safety, thus makes it way less error-prone. Combined with new static analyzers (phpstan, php-cs-fixer, psalm - take your pick), you find possible errors way earlier now. I think it gets a lot of inspiration from Java. Symfony gets lots of inspiration from Spring Boot. The Twig templating language is heavily related to the Django templating language. So many of the tools and concepts are somewhat battle-tested. And this is on top of the huge performance improvements in the last years. So yeah, there's many things that are still fixable. But the improvements have been staggering.
oooyay 3y ago
This got me thinking if any of my side projects or work projects that are in maintenance mode could qualify as "cold blooded". Conceptually, they can - I have many projects written in Go, Typescript, and Python where I could cache my dependencies (or at least the SHAs) and do what this is implying. The problem is that it stops being useful beyond proving the concept. In reality, all my projects have a slow churn that usually has to do with vulnerability updates. Maybe more aptly put, "Can I take this Go repository off the shelf, rebuild the binary, and let it run?"; the answer is of course - assuming HTML and web standards haven't changed too much. The problem is that then some old vulnerability could be immediately used against it. The assumption I also made, that HTML and web standards haven't changed too much, will almost assuredly be falsey. They may have not have changed enough to be breaking, but they'll have certainly changed to some degree; the same can be said for anyone that's developed desktop applications for any OS. The one constant is change. Either side of that coin seems to be a losing proposition.
__natty__ 3y ago
In the Node & JavaScript ecosystem, there is the web framework Express. The current major version 4.x.x branch is over 10 years old [1]. And yet it powers so many apps in the ecosystem (over 17M downloads every week [2]). It lacks some features and is not the most performant [3]. But me and coworkers I talked with, like it because it allows for quick, stable development and long-term planning without worrying about drastic API changes and lack of security patches for older versions. Even better stability is provided with Go where we can run over 10-year-old programs thanks to a mix of wide stdlib and the promise of compatibility. [4] [1] https://www.npmjs.com/package/express?activeTab=versions https://www.npmjs.com/package/express?activeTab=versions [2] https://www.npmjs.com/package/express https://www.npmjs.com/package/express [3] https://fastify.dev/benchmarks/ https://fastify.dev/benchmarks/ [4] https://go.dev/doc/go1compat https://go.dev/doc/go1compat
- steve_adams_86 3y ago
  This gave me a pleasant shock. I'd forgotten that Express has been around for 13 years now. It was considered a super shoddy, pretend-programmer piece of junk by many when it first arrived (largely by virtue of being written in JavaScript). Since then I've helped a lot of companies build cool stuff that made real money with it. It's probably serving a crazy number of requests these days. I write a lot of things with Go now instead, but I'm still totally content to build things with Express. It's good software, generally speaking.
- rareitem 3y ago
  Express v5 is allegedly coming out in the near future (https://github.com/expressjs/express/issues/4920 https://github.com/expressjs/express/issues/4920)
  - pcthrowaway 3y ago
    And that's been in production for over 8 years https://github.com/expressjs/express/issues/2755 https://github.com/expressjs/express/issues/2755
  - erikpukinskis 3y ago
ChrisMarshallNY 3y ago
I wrote an SDK, in 1994-95, that was still in use, when I left the company, in 2017. It was a device control interface layer, and was written in vanilla ANSI C. Back when I wrote it, there wasn't a common linker, so the only way to have a binary interface, was to use simple C. I have written stuff in PHP (5), that still works great, in PHP 8.2. Some of that stuff is actually fairly ambitious. But it's boring, and has a low buzzword index.
d_burfoot 3y ago
This essay showcased an excellent writing technique: at the outset, I had no idea what the title meant. But at the conclusion, it made perfect sense.
- lioeters 3y ago
  I also liked that it started with a little story about the frozen turtle slowly coming back to life.
js8 3y ago
I work on IBM mainframe (z/OS). Nothing else I know comes as close in maintaining backwards compatibility as IBM. Microsoft (Windows) is the 2nd, I think. Linux (kernel) ABI has the 3rd place, but that's only a small portion of Linux ecosystem. Almost everything else, it's just churn. In OSS this is common, I guess nobody wants to spend time on backward compatibility as a hobby. From an economic perspective, it looks like a prisoner's dilemma - everybody externalizes the cost of maintaining compatibility onto others, collectively creating more useless work for everybody.
- userbinator 3y ago
  In OSS this is common, I guess nobody wants to spend time on backward compatibility as a hobby. There's a lot of chasing new and shiny in OSS but I wouldn't say that applies to everyone... just look at the entire retrocomputing community, for example. Writing drivers for newer hardware to work on older OSes is not unheard of.
  - js8 3y ago
    These are amazing people, and I like what they do, but they are still chasing the churn of newer hardware, which also introduces incompatible APIs. The incompatible APIs are often introduced commercially for business and not technical reasons, either out of ignorance, legal worries or in order to gain a market advantage.
- matheusmoreira 3y ago
  > I guess nobody wants to spend time on backward compatibility as a hobby. Getting paid to maintain something certainly goes a long way. Without payment, I suppose it comes down to how much one cares about the platform being built. I deliberately chose to target the Linux kernel directly via system calls because of their proven commitment to ABI stability. On the other hand, I made my own programming language and I really want to make it as "perfect" as possible, to get it just right... So I put a notice in the README that explains it's in early stages of development and unstable, just in case someone's crazy enough to use it. I have no doubt the people who work on languages like Ruby and Python feel the same way... The languages are probably like a baby to them, they want people to like it, they want it to succeed, they just generally care a lot about it. And that's why mistakes like print being a keyword just have to be fixed.
deleted 3y ago
[deleted]
imglorp 3y ago
Worth mentioning the Hare language, designed to be stable for 100 years. After they release 1.0 they don't plan to change it beyond fixes. It's Drew DeVault's project. https://harelang.org/roadmap/ https://harelang.org/roadmap/
userbinator 3y ago
I have some Windows binaries from the mid 90s that I still use today. Mainly small utilities for various calculations/conversions, filesystem organisation, and the like.
johnnyworker 3y ago
I kept making CMS as a hobby, starting with flat files and PHP, moving to MySQL.. simple things. I did it precisely because I figured if I modify and write plugins for Wordpress, I would have to keep updating them on their schedule. Especially since even back then I really liked removing things I don't want, and while carrying over additions I created over to new versions might be easy enough, maintaining a stripped down version of something like Wordpress (even 20 years ago..) would have been impossible. I felt like a stubborn dumb ass in the early 2000s (and there was also this constant mockery of "NIH syndrome" in the air) but by now, I'm so glad I basically disregarded a lot of stuff and just made my own things out of the basics. And coincidentally, the last one I made has also lasted me over 12 years by now. I still love it actually, it's just the code that is terrible. So I started a new one, to fix all the mistakes of the previous one, which mostly is cutting less corners because now I know that I'll use this for way longer than I can reasonably estimate right now, so I try to be kind(er) to future me. (But I'll also make fascinating new mistakes, because I decided to de-duplicate more or less everything at the DB level, on a whim, without prior experience or reading up on it. And then I'll write some monstrosity to pipe 12 years of content from the old CMS into the new one, and I will not break a single link even though nobody would really care. Just because I can.)
synack 3y ago
If you limit your dependencies to what’s available in your distro’s LTS or stable release breaking changes are much less common. Living on the bleeding edge has a cost.
talentedcoin 3y ago
Using Python 2 in 2023 for a new project is a crime
jes5199 3y ago
I’ve got a similar one, yet to be written, about “cold computing”. How do you compute if you’re on a limited solar+battery installation? what if your CPU wakes up and you have only a couple of hours of runtime? What if you only can turn on wifi for 20 minutes a day?
- g8oz 3y ago
  This sounds very interesting, please do write it up.
ranger207 3y ago
The only software that can go without updates is software that gets it right the first time If you're building software for yourself, this is relatively easy. Your tastes probably won't change that much even after a decade. You can probably ignore minor problems like using an O(n^2) function where there exists an O(n) because n is small. If you're writing software that other people will use, then that's where the problems come in. Other people don't have the same requirements as you, and may have a large enough N that the O(n) function makes it worth it, for example. But regardless of if you're writing for yourself or someone else, sometimes you just can't foresee problems. Maybe it crashes processing files larger than a gig, but because you've only ever used files <100KB it's never mattered to you. Then you go in to fix the crash and it turns out you're going to have to rewrite half the thing. This is, I think, the biggest argument against the idea that software that doesn't change is inherently better than software that changes frequently[0]: it may be that unchanging software was perfect from the first line, or it may be that there's terrors lurking in the deep, and a priori it can be difficult to tell which a particular project is. [0] This is not to say that rapidly updating software is inherently better than slowly updating software either. There's many factors other than just update speed
- fauigerzigerk 3y ago
  I don't think the idea is that software should never change. If requirements change then software obviously has to change as well. But over the course of 10 years a lot of things can change that have nothing to do with changing requirements. Open source projects are abandoned or change direction. Commercial software gets discontinued. Companies get acquired. App Store / Play Store rules change. APIs go away or change pricing in ways that render projects economically unviable. Toolchains, frameworks and programming languages, paradigms and best practices change. I think the point is that you don't want external changes that are unrelated to your requirements to force change on you. It's a good principle but as always there are trade-offs. There is stable and then there is obsolete. The difference is often security. And what if an important new requirement is easy to meet, but only if you bump a vendored library by seven major versions causing all sorts of unrelated breakage? What if there aren't enough people left who are familiar with your frozen-in-time toolset and nobody wants to learn it any longer? I think careful and even conservative selection of dependencies is a good idea, but not keeping up with changes in that hopefully small set of dependencies is one step too far for me.
secwang 3y ago
c , Common Lisp , apl All of these have a solid history of backward compatibility.
zubairq 3y ago
I had to read this article a couple of times before I got it. I guess dependencies can make an app warm blooded, but Docker or containerization can also paper over some of these issues. However, whenever I choose libraries for a project I do alot of research to make sure that the libraries themselves are "cold blooded" too, as even one badly chosen library can cause your project to fail in 10 years time
DeathArrow 3y ago
Cold blooded: random utility written in C 40 years ago. Warm blooded: random app using random Javascript framework, written 6 months ago.
kirillrogovoy 3y ago
One interesting thing about learning Elixir and its (+Erlang) ecosystem after 5+ years of JS/TS is that half of the most popular libraries seemed abandoned. However, when you look closer, turns out that most of them just finished the work within their scope, fixes all reproducible bugs, and there's just not much left to do. If there's a JS dependency with the last commit in 2022, it probably won't even build. (I'm half-joking of course, but only half)
- sergiomattei 3y ago
  I noticed this too and I’m still getting used to it.
pqwEfkvjs 3y ago
hot bloodedness ~= num dependencies
jviotti 3y ago
Great article. I try to follow this advice as much as I can. My personal website (https://www.jviotti.com https://www.jviotti.com) runs almost purely on well established UNIX tools like Make, Pandoc, Sed, etc. Repository here: https://github.com/jviotti/website https://github.com/jviotti/website.
deterministic 3y ago
I love cold-blooded software and avoid unstable-ever-changing software as much as possible. Why? Because I can then focus 99% on delivering customer value instead of constantly rewriting code that used to work just fine but now doesn’t because some inexperienced snowflake narcissistic developer decide to make arbitrary changes to an API that worked perfectly fine for years! Sorry a bit of a rant there. Unstable software makes me want to throw my PC out of the nearest window.

558 points by arbesman 3y ago

Counterpoint: some types of software aren’t meant to last long. Even if it still builds and can be worked on later, the usecase itself may have changed or disappeared, or someone has probably come up with a new better version, so that it’s no longer worth it to continue. This probably doesn’t apply to many types of software over 6 months, but in a couple years or a couple decades. Some online services like CI or package managers will almost certainly provide backwards-compatible service until then. Another possibility is that developer efficiency improves so much that the code written 10 years ago is easier to completely rewrite today, than it is to maintain and extend. This is why I’m hesitant to think about software lasting decades, because tech changes so fast it’s hard to know what the next decade will look like. My hope is that in a few years, LLMs and/or better developer tools will make code more flexible, so that it’s very easy to upgrade legacy code and fix imperfect code.

iamthepieman 3y ago
"Another possibility is that developer efficiency improves so much that the code written 10 years ago is easier to completely rewrite today, than it is to maintain and extend." This seems completely false to me and I'm curious what has caused you to believe this as I'm a fairly imaginative and creative person yet I cannot imagine a set of circumstance that would lead someone to this conclusion. In other words, I disagree so very strongly with that statement that I wanted to engage rather than just downvote. (I didn't btw). I agree with your first statement though and I don't think the op is saying only make cold-blooded projects.
- dartos 3y ago
  Well. I don’t know if I agree or not, but felt like playing devils advocate. take the example of game development. Trying to maintain, say, the hobbit game from the early 2000s to today would almost certainly take more work than just making a new one from scratch today (GPUs have changed drastically over the past 20 years and making simple 3d platformers with unreal is so easy, “asset flips” are a new kind of scam) Or a tool which lets people visually communicate over vast distances without specialized hardware. That was a huge lift in the 2000s when Skype was the only major player, but you can find tutorials for it now using webrtc.

languagehacker 3y ago

Cold-blooded software seems like a great idea in spaces where the security risk and business impact are low. I can think of a lot of great hobbyist uses for this approach, like a handmade appliance with Arduino or Raspberry Pi. The ever-evolving threat landscape at both the OS and application level makes this unviable for projects with any amount of money or sensitivity behind them. Imagine needing to handle an OS-level update and learning that you can no longer run Python 2 on the box you're running that project on. Fine for a blog, but calamitous for anything that handles financial transactions.

kardianos 3y ago
If you are a bank, a store, or handle PHI, you will have contractual obligations to maintain it. However, I still think that can be "cold-blooded" maintenance. When I update a Go project after running `govulncheck ./...`, it is generally easy. I vendor; builds and runtime only rely on systems I control.
- apantel 3y ago
  Many large companies and business like banks and manufacturers run legacy code in ancient runtimes. The projects can be so frozen in time that nobody has the courage to touch them.
joshuaissac 3y ago
> Cold-blooded software seems like a great idea in spaces where the security risk and business impact are low. I can think of a lot of great hobbyist uses for this approach, like a handmade appliance with Arduino or Raspberry Pi. I think it would be the other way around. A low-impact hobby project can use exciting, fast-moving technology because if it breaks, there is not so much damage (move fast and break things). But something with high business impact should use boring, tried-and-tested technologies no external network dependencies (e.g. a package being available in a third-party repository at compile time or runtime). For something like that, the OS updates (on the LTS branch if Linux) would be planned well ahead, and there would be no surprises like the Python 2 interpreter suddenly breaking.
3y ago

082349872349872 3y ago

I suspect our differences in preferences for cold- vs warm-blooded projects may be related to the "Buxton Index" as mentioned in https://www.cs.utexas.edu/users/EWD/transcriptions/EWD11xx/EWD1175.html https://www.cs.utexas.edu/users/EWD/transcriptions/EWD11xx/E...

chrisweekly 3y ago
Curious, I read the linked transcript to find: "My third remark introduces you to the Buxton Index, so named after its inventor, Professor John Buxton, at the time at Warwick University. The Buxton Index of an entity, i.e. person or organization, is defined as the length of the period, measured in years, over which the entity makes its plans. For the little grocery shop around the corner it is about 1/2,for the true Christian it is infinity, and for most other entities it is in between: about 4 for the average politician who aims at his re-election, slightly more for most industries, but much less for the managers who have to write quarterly reports. The Buxton Index is an important concept because close co-operation between entities with very different Buxton Indices invariably fails and leads to moral complaints about the partner. The party with the smaller Buxton Index is accused of being superficial and short-sighted, while the party with the larger Buxton Index is accused of neglect of duty, of backing out of its responsibility, of freewheeling, etc.. In addition, each party accuses the other one of being stupid. The great advantage of the Buxton Index is that, as a simple numerical notion, it is morally neutral and lifts the difference above the plane of moral concerns. The Buxton Index is important to bear in mind when considering academic/industrial co-operation."
- salawat 3y ago
  Holy shit. I am so using this as a communication clarifying tool. Nice concept.
- apantel 3y ago
  Great concept, but isn’t it just “time horizon”? Everyone knows “time horizon”.
  - 3y ago

jollyllama 3y ago

This is why I am trying to switch as many projects I'm on as possible to HTMX. The churn involved with all of the frontend frameworks means that there's far too much update work needed after letting a project sit for N quarters.

mikewarot 3y ago
I googled HTMX, all excited that maybe, just maybe, the browser people got their shit together and came up with a framework we can all live with, something native to the browser with a few new tags, and no other batteries required.... and was disappointed to find it's just a pile of other libraries 8(
- dartos 3y ago
  Everything is a pile of libraries. It’s a pile of someone else’s code all the way down.
  - diggan 3y ago
    You can also use the web platform straight up without transpilation, build tools, post-css compilation and all that jazz. Just vanilla JavaScript, CSS, HTML, some sprinkles of WebComponents. And you can be pretty sure that you won't have to update that for a decade or more, as compatibility won't be broken in browsers. Heck, I have vanilla JS projects I wrote 15 years ago that still render and work exactly like how they rendered/worked when I wrote them.
    - jollyllama 3y ago
      Indeed, that baggage is all that I avoid by using HTMX.
      - diggan 3y ago
        You do you. It's worth knowing though that using HTMX is not vanilla JS/HTML/CSS, it's literally the opposite of that.

ryanar 3y ago

I really appreciate this idea after rewriting my blog engine three times because the frameworks I was using (Next, Remix) had fundamental changes after a year and I was multiple major versions behind. Though it depends on what you are after. If the goal is to be able to blog, time spent upgrading and rewriting code because the framework is evolving is wasted time unless you want to stay up to date with that framework. Think about how we view physical goods today, they aren’t built to last. In certain situations, like a personal blog, you want reliable software that works for years without the need to change. It also helps to have software that uses common data formats that are exportable to another system, like a blog based in markdown files, rather than JSX.

layer8 3y ago

I’m glad this isn’t about ruthless software.

jujube3 3y ago
Look at that subtle off-white colouring of the project landing page. The tasteful thickness of it. Oh my God, it even has a watermark!

vrnvu 3y ago

one thing I’ve noticed is that many engineers, when they’re looking for a library on Github, they check the last commit time. They think that the more recent the last commit is, the better supported the library is. But what about an archived project that does exactly what you need it to do, has 0 bugs, and has been stable for years? That’s like finding a hidden gem in a thrift store! Most engineers I see nowadays will automatically discard a library that is not "constantly" updated... Implying it's a good thing :)

pmichaud 3y ago
Even though it’s not strictly true, checking for recent updates is an excellent heuristic. I don’t know the real numbers, but I feel confident that in the overwhelming majority of cases, no recent activity means “abandoned”, not “complete and bug free”.
scruple 3y ago
I'm generally doing that to check for version compatibility across a much broader spectrum than the level of a single library.
fabian2k 3y ago
A library can only stay static if the environment it's used in is also static. And many of the environments in which modern software is developed are anything but static, web frontends are one example where things change quite often. A library that can stand entirely on its own might be fine if it's never updated. But e.g. a library that depends on a web frontend framework will cause trouble if it is not updated to adapt to changes in the ecosystem.
- adonovan 3y ago
  Also, even a very stable project that is "done" will receive a trickle of minor tweak PRs (often docs, tests, and cleanups) proportional to the number of its users, so the rate of change never falls to zero until the code stops being useful.
  - 3y ago

kageiit 3y ago

For many use cases, cold-blooded software is not viable. We need better tools to automate and remove the tedium involved in upgrading dependencies or modernizing codebases to protect against ever evolving threats and adapt to changes in the ecosystem

tlhunter 3y ago

I love the sentiment of this post. I absolutely hate that my recent mobile apps from only a couple years ago l now require a dozen hours to patch them up and submit updates. The author's final point is interesting wherein they refer to their own static site generator as being cold-blooded and that it runs on Python 2. Python 2 is getting harder to install recently and will eventually make it a warm blooded project.

ryandrake 3y ago
I have a little hobby project (iOS and macOS) that I don't regularly develop anymore, but I use it quite often as a user, and I like to keep it compiling and running on the latest OSes. It's aggravating (and should be totally unacceptable) that every time I upgrade Xcode, I have a few odds and ends that need to be fixed in order for the project to compile cleanly and work. My recent git history comments are all variations of "Get project working on latest Xcode". I could almost understand if these underlying SDK and OS changes had to be made due to security threats, but that's almost never the case. It's just stupid things like deprecating this API and adding that warning by default and "oh, now you need to use this framework instead of that one". Platforms and frameworks need to stop deliberately being moving targets, especially operating systems that are now very stable and reliable. I should be able to pull a 10 year old project out of the freezer and have it compile cleanly and run just as it ran 10 years ago. These OS vendors are trillion dollar companies. I don't want to hear excuses about boo hoo how much engineering effort backward compatibility is.
- dartos 3y ago
  Hardware changes over 10 years. Macs don’t even run on the same CPU architecture or support OpenGL. Sometimes things just need to change.
  - beambot 3y ago
    The worst is when your virtualization environments intended to provide long-term support don't even accomodate the "new" mainline hardware. Most frustrating example: Virtualbox doesn't work on Apple M1 or M2 chipsets.

sowbug 3y ago

A link to this article would be an effective curt reply to the "is this project dead?" GitHub issues that have been known to enrage and discourage cold-blooded project owners.

bee_rider 3y ago
I wonder if GitHub is a bad fit for cold blooded projects? It has social media elements, I’d expect lots of extra chatter and “engagement.”

coreyp_1 3y ago

This. This, so very much! I built my websites on Drupal 7 and have enjoyed a decade of stability. Now, with D7 approaching EOL in 1 year, I'm looking for a solution that will last another decade. There's no reason for the EOL, either, other than people wanting to force everyone to move on to a newer version. It undoubtedly means more business for some people, as they will be able to reach out to their clients and say, "Your website is about to be a security risk, so you have to pay to update it!" Unfortunately, it means more work for me to support my personal projects. And why? Because someone somewhere has decided that I should move on to something newer and more exciting. But I don't want new and exciting... I want rock solid! I'm on vacation this week. Am I learning a new hot language like Rust, Zig, Go, etc.? Nope. I have no desire to. I don't trust them to be the same in a decade, anyway. I'm focusing on C. It's far more enjoyable, and it's stable.

dartos 3y ago
Enjoyable is subjective. I can’t think of anything less enjoyable than hunting for segfaults in C. I’d call Go pretty rock solid at this point. Modern go vs decade old go isn’t very different. Maybe just the packages tools had 1 major changed. You’d get the same thing in C if your hardware significantly changes in the 10 years too.
- coreyp_1 3y ago
  Haha... I agree about it being subjective! I find that I enjoy the process as much as the result. It's like bringing order to a chaotic universe. :) The thing is, I don't have many segfaults in C, and I find C much easier to debug and hunt down issues in than even C++ (which I also enjoy). Also, because C uses very little "magic", and I also know exactly what I'm getting with my code, I find it much easier to reason about. I heard a quote the other day while watching a presentation "When you're young you want results, when you're old you want control." I think I'm on the old side now. As for Go, I genuinely don't have anything against it, but I don't see why I need it either. I don't doubt that others have stellar use cases and impressive results with Go, and that's fine, too, but I don't sense any lack which prompts me to investigate further. I would love to learn more about it, but most of what I see online is either over-the-top (and therefore vomit-inducing) fanboyism, or otherwise unspectacular, which makes me ask "why bother?"

hiAndrewQuinn 3y ago

Most of the software I write is at least somewhat cold-blooded by this definition. My program to find the dictionary forms of Finnish words is an okay example: https://github.com/hiAndrewQuinn/finstem https://github.com/hiAndrewQuinn/finstem I wrote the initial draft in an afternoon almost a year ago, and from then on endeavored to only make changes which I know play nicely with my local software ecology. I usually have `fzf` installed, so an interactive mode comes as a shell script. I usually have `csvkit`, `jq`, and if all else fails `awk` installed, so my last major update was to include flags for CSV, JSON, and TSV output respectively. Etc, etc. The build instructions intentionally eschew anything like Poetry and just gives you the shell commands I would run on a fresh Ubuntu VirtualBox VM. I hand test it every couple of months in this environment. If the need to Dockerize it ever arose I'm sure it would be straightforward, in part because the shell commands themselves are straightforward. I don't call it a great example because the CLI library I use could potentially change. Still, I've endeavored to stick to only relatively mature offerings.

csdvrx 3y ago

I follow a similar approach but maybe more extreme : whenever possible, I use "YESTERDAY'S TECHNOLOGY TOMORROW" It's nicely presented on http://itre.cis.upenn.edu/~myl/languagelog/archives/000606.html http://itre.cis.upenn.edu/~myl/languagelog/archives/000606.h... > I want yesterday's technology tomorrow. I want old things that have stood the test of time and are designed to last so that I will still be able to use them tomorrow. I don't want tomorrow's untested and bug-ridden ideas for fancy new junk made available today because although they're not ready for prime time the company has to hustle them out because it's been six months since the last big new product announcement. Call me old-fashioned, but I want stuff that works. The same thing is true with free software: I prefer to use the terminal. In the terminal, I prefer to run bash and vim, not zsh and neovim. When I write code, I've found C (and perl!) to be preferable, because "You can freeze it for a year and then pick it back up right where you left off." There are rare exceptions, when what's new is so much better than the previous solution (ex: Wayland) that it makes sense to move. However, that should be rare, and you should be very sure. If you think you made the wrong choice, you can always move back to your previous choice: after playing with ZFS for a few years, I'm moving some volumes back to NTFS. Someone mentions how the author choice (python2) is getting harder to install. Cold blooded software works best when done with multiplatform standards, so I'd suggest the author does the bare minimum amount of fixes necessary to run with https://cosmo.zip/pub/cosmos/bin/python https://cosmo.zip/pub/cosmos/bin/python and call it a day. With self-contained APEs and the eventual emulator when say 20 years from now we move to Risc V, you don't have to bother about dependencies, updates or other form of breakage: compile once in a APE form (statically linked for Windows/Linux/BSD/MacOS) it will run forever by piggybacking on the popularity of the once-popular platform. Wine lets you run Windows 95 binaries about 30 years layer: I'd bet than Wine + the Windows part of the APE will keep running long after the kernel break the ABI.

slaymaker1907 3y ago

Besides what is stated in the article, it is also important to have an inherently secure threat model. For example, full websites are inherently warm-blooded since you are constantly dealing with attackers, spam bots, etc. However, static pages like Tiddlywiki are a lot better since you can avoid putting it on the web at all and browsers are incredibly stable platforms.

ganzuul 3y ago

https://en.wikipedia.org/wiki/Unix_philosophy https://en.wikipedia.org/wiki/Unix_philosophy Seems related. Tools built like this which still need constant updating must have a foundation of sand.

imran-iq 3y ago

Python is a really bad example of cold blooded software. There is constant breaking changes with it (both runtime and tooling). So much so that the author still has to use python2 which has been EOL'd for quite a while. A much better example would be something like go or java where 10 year old code still runs fine with their modern tooling. Or an even better example, perl, where 30 year old code still runs fine to this day

082349872349872 3y ago
2 and 3 don't really differ that much; true cold-blooded software doesn't care which it's being run with.
JohnFen 3y ago
Agreed. This is one of the reasons why I avoid using Python whenever possible. Python code I write today is unlikely to be functional years from now, and I consider that a pretty huge problem.
- heurist 3y ago
  This really depends on your environment. I've been running legacy Python servers continuously for 4+ years without breaking them or extensively modifying them because I invested in the environment and tooling around it (which I would do for any app I deploy). I can't say I want to bring all of them entirely up to date with dependencies, but they're still perfectly functional. Python is pretty great, honestly. I rarely need to venture into anything else (for the kind of work I do).
  - JohnFen 3y ago
    > I've been running legacy Python servers continuously for 4+ years That seems like a large amount of effort to make up for a large language deficiency. My (heartfelt) kudos to you! I might have been willing to do the same if I used Python heavily (I don't because there are a number of other things that makes it very much "not for me") -- but it would still represent effort that shouldn't need to be engaged in.

iqandjoke 3y ago

How about security?

aranchelk 3y ago

In my mind this is a lot more about tooling and platform than language, library, architecture, etc. I have a project that’s quite complicated and built on fast-moving tech, but with every element of the build locked down and committed in SCM: Dockerfiles, package sets, etc. Alternatively, one of my older projects uses very stable slow-moving tech. I never took the time to containerize and codify the dependencies. It runs as an appliance and is such a mess that it’s cheaper to buy duplicates of the original machine that it ran on and clone the old hard drive rather than do fresh installs.

blastbking 3y ago

I had this experience making an iOS game. After a few years of making the game, I went back to it, and found that I was unable to get it to compile. I guess iOS games are very warm blooded. Perhaps if I had stuck with a desktop platform or web it would have remained fine? Not entirely sure.

yellow_lead 3y ago
Mobile in general is this way. For instance, on Android, if your app isn't targeting a high enough sdk version, Google will remove it after some time. If you have to upgrade your target sdk, you may find many libraries are broken (or not supported), and it also can lead to other cascades of upgrades, like having to upgrade gradle or the NDK if you use it.

petercooper 3y ago

I think Go's backward compatibility promise – https://go.dev/blog/compat https://go.dev/blog/compat – would make much Go software 'cold blooded' by this definition (so long as you vendor dependencies!)

aeternum 3y ago

What a terrible name for this. Cold blooded animals are highly dependent on their environment whereas the body of warm-blooded animals eliminate the dependency on external temperature via metabolism. In any case, it's unnecessarily ambiguous. Why not simply say 'software without external dependencies' and eliminate the paragraphs of meandering explanation?

littleroot 3y ago
This is literally the only reply that hit the core of the article's problem and of course no one on this site upvoted it lol. The only thing I dislike more than software development posts that use inappropriate analogy from nature to shallowly jump to conclusion, is software development posts that use inappropriate analogy from nature to shallowly jump to conclusion with absolutely flawed understanding of the supposedly analogous natural phenomenon. And of course, painted turtles (among a few other species) can survive being frozen not because of their cold-bloodedness, but thanks to special antifreeze protein they have. Other lizards (and cold blooded animals for that matter) would just rupture their own tissues upon thawing.
aebtebeten 3y ago
Here's someone who was more charitable with their biological interpretation: https://lobste.rs/s/hitos3/cold_blooded_software#c_mxjzwh https://lobste.rs/s/hitos3/cold_blooded_software#c_mxjzwh

kugelblitz 3y ago

I've been maintaining my own side project. It started 12-13 years ago, with vanilla php, later rewritten with Laravel, later rewritten again with Symfony in 2017-ish. Since then I've had phases from 6-18 months where I had a total of 2-3 tiny commits (I was working full time as a freelancer, so I didn't have energy to work on my side project). But then when I had time, I would focus on it, add features, upgrade and just experiment and learn. This was super valuable to me to learn how to maintain projects long-term: Update dependencies, remove stuff you don't need, check for security updates, find chances to simplify (e.g. from Vagrant to Docker... or from Vue + Axios + Webpack + other stuff to Htmx). And what to avoid... for me it was to avoid freshly developed dependencies, microservices, complexified infrastructure such as Kubernetes. And now I just developed a bunch of features, upgraded to PHP 8.2 and Symfony 7 (released a month ago), integrated some ChatGPT-based features and can hopefully relax for 1-3 years if I wanted to. In the last 4-5 years the project has made about the same revenue as an average freelance year's revenue, so it's not some dormant unknown side project.

Aeolun 3y ago
I think PHP, as horrible as it feels to go back, is one example of something that’s truly backwards compatible even to its own detriment. Haven’t worked with it for years, went back to find that the horrible image manipulation functions are still the same mess that I left behind 8 years ago.
- kugelblitz 3y ago
  Yeah, some things are still a mess, but many things I use constantly have improved so much. Here is an excerpt of a function that shows many of the updates that I use regularly: #[AsMessageHandler] readonly class JobEditedHandler { public function __construct( private Environment $twig, private EmailService $mailer, private string $vatRate, ) {} public function __invoke(JobEdited $jobEdited): void { $this->sendNotificationToJobPublisher($jobEdited); } You have attributes, much better type-hinting, constructor property promotion, read-only properties / classes. Additionally you have native Enums, named arguments and also smaller things such as match expressions (instead of case switch), array spread operator, null coalescing assignment operator, etc, etc. Especially in a CRUD-heavy setting like mine (I run a niche jobboard) it reduces so much boilerplate and increases type-safety, thus makes it way less error-prone. Combined with new static analyzers (phpstan, php-cs-fixer, psalm - take your pick), you find possible errors way earlier now. I think it gets a lot of inspiration from Java. Symfony gets lots of inspiration from Spring Boot. The Twig templating language is heavily related to the Django templating language. So many of the tools and concepts are somewhat battle-tested. And this is on top of the huge performance improvements in the last years. So yeah, there's many things that are still fixable. But the improvements have been staggering.

oooyay 3y ago

This got me thinking if any of my side projects or work projects that are in maintenance mode could qualify as "cold blooded". Conceptually, they can - I have many projects written in Go, Typescript, and Python where I could cache my dependencies (or at least the SHAs) and do what this is implying. The problem is that it stops being useful beyond proving the concept. In reality, all my projects have a slow churn that usually has to do with vulnerability updates. Maybe more aptly put, "Can I take this Go repository off the shelf, rebuild the binary, and let it run?"; the answer is of course - assuming HTML and web standards haven't changed too much. The problem is that then some old vulnerability could be immediately used against it. The assumption I also made, that HTML and web standards haven't changed too much, will almost assuredly be falsey. They may have not have changed enough to be breaking, but they'll have certainly changed to some degree; the same can be said for anyone that's developed desktop applications for any OS. The one constant is change. Either side of that coin seems to be a losing proposition.

__natty__ 3y ago

In the Node & JavaScript ecosystem, there is the web framework Express. The current major version 4.x.x branch is over 10 years old [1]. And yet it powers so many apps in the ecosystem (over 17M downloads every week [2]). It lacks some features and is not the most performant [3]. But me and coworkers I talked with, like it because it allows for quick, stable development and long-term planning without worrying about drastic API changes and lack of security patches for older versions. Even better stability is provided with Go where we can run over 10-year-old programs thanks to a mix of wide stdlib and the promise of compatibility. [4] [1] https://www.npmjs.com/package/express?activeTab=versions https://www.npmjs.com/package/express?activeTab=versions [2] https://www.npmjs.com/package/express https://www.npmjs.com/package/express [3] https://fastify.dev/benchmarks/ https://fastify.dev/benchmarks/ [4] https://go.dev/doc/go1compat https://go.dev/doc/go1compat

steve_adams_86 3y ago
This gave me a pleasant shock. I'd forgotten that Express has been around for 13 years now. It was considered a super shoddy, pretend-programmer piece of junk by many when it first arrived (largely by virtue of being written in JavaScript). Since then I've helped a lot of companies build cool stuff that made real money with it. It's probably serving a crazy number of requests these days. I write a lot of things with Go now instead, but I'm still totally content to build things with Express. It's good software, generally speaking.
rareitem 3y ago
Express v5 is allegedly coming out in the near future (https://github.com/expressjs/express/issues/4920 https://github.com/expressjs/express/issues/4920)
- pcthrowaway 3y ago
  And that's been in production for over 8 years https://github.com/expressjs/express/issues/2755 https://github.com/expressjs/express/issues/2755
- erikpukinskis 3y ago

ChrisMarshallNY 3y ago

I wrote an SDK, in 1994-95, that was still in use, when I left the company, in 2017. It was a device control interface layer, and was written in vanilla ANSI C. Back when I wrote it, there wasn't a common linker, so the only way to have a binary interface, was to use simple C. I have written stuff in PHP (5), that still works great, in PHP 8.2. Some of that stuff is actually fairly ambitious. But it's boring, and has a low buzzword index.

d_burfoot 3y ago

This essay showcased an excellent writing technique: at the outset, I had no idea what the title meant. But at the conclusion, it made perfect sense.

lioeters 3y ago
I also liked that it started with a little story about the frozen turtle slowly coming back to life.

js8 3y ago

I work on IBM mainframe (z/OS). Nothing else I know comes as close in maintaining backwards compatibility as IBM. Microsoft (Windows) is the 2nd, I think. Linux (kernel) ABI has the 3rd place, but that's only a small portion of Linux ecosystem. Almost everything else, it's just churn. In OSS this is common, I guess nobody wants to spend time on backward compatibility as a hobby. From an economic perspective, it looks like a prisoner's dilemma - everybody externalizes the cost of maintaining compatibility onto others, collectively creating more useless work for everybody.

userbinator 3y ago
In OSS this is common, I guess nobody wants to spend time on backward compatibility as a hobby. There's a lot of chasing new and shiny in OSS but I wouldn't say that applies to everyone... just look at the entire retrocomputing community, for example. Writing drivers for newer hardware to work on older OSes is not unheard of.
- js8 3y ago
  These are amazing people, and I like what they do, but they are still chasing the churn of newer hardware, which also introduces incompatible APIs. The incompatible APIs are often introduced commercially for business and not technical reasons, either out of ignorance, legal worries or in order to gain a market advantage.
matheusmoreira 3y ago
> I guess nobody wants to spend time on backward compatibility as a hobby. Getting paid to maintain something certainly goes a long way. Without payment, I suppose it comes down to how much one cares about the platform being built. I deliberately chose to target the Linux kernel directly via system calls because of their proven commitment to ABI stability. On the other hand, I made my own programming language and I really want to make it as "perfect" as possible, to get it just right... So I put a notice in the README that explains it's in early stages of development and unstable, just in case someone's crazy enough to use it. I have no doubt the people who work on languages like Ruby and Python feel the same way... The languages are probably like a baby to them, they want people to like it, they want it to succeed, they just generally care a lot about it. And that's why mistakes like print being a keyword just have to be fixed.

deleted 3y ago

[deleted]

imglorp 3y ago

Worth mentioning the Hare language, designed to be stable for 100 years. After they release 1.0 they don't plan to change it beyond fixes. It's Drew DeVault's project. https://harelang.org/roadmap/ https://harelang.org/roadmap/

userbinator 3y ago

I have some Windows binaries from the mid 90s that I still use today. Mainly small utilities for various calculations/conversions, filesystem organisation, and the like.

johnnyworker 3y ago

I kept making CMS as a hobby, starting with flat files and PHP, moving to MySQL.. simple things. I did it precisely because I figured if I modify and write plugins for Wordpress, I would have to keep updating them on their schedule. Especially since even back then I really liked removing things I don't want, and while carrying over additions I created over to new versions might be easy enough, maintaining a stripped down version of something like Wordpress (even 20 years ago..) would have been impossible. I felt like a stubborn dumb ass in the early 2000s (and there was also this constant mockery of "NIH syndrome" in the air) but by now, I'm so glad I basically disregarded a lot of stuff and just made my own things out of the basics. And coincidentally, the last one I made has also lasted me over 12 years by now. I still love it actually, it's just the code that is terrible. So I started a new one, to fix all the mistakes of the previous one, which mostly is cutting less corners because now I know that I'll use this for way longer than I can reasonably estimate right now, so I try to be kind(er) to future me. (But I'll also make fascinating new mistakes, because I decided to de-duplicate more or less everything at the DB level, on a whim, without prior experience or reading up on it. And then I'll write some monstrosity to pipe 12 years of content from the old CMS into the new one, and I will not break a single link even though nobody would really care. Just because I can.)

synack 3y ago

If you limit your dependencies to what’s available in your distro’s LTS or stable release breaking changes are much less common. Living on the bleeding edge has a cost.

talentedcoin 3y ago

Using Python 2 in 2023 for a new project is a crime

jes5199 3y ago

I’ve got a similar one, yet to be written, about “cold computing”. How do you compute if you’re on a limited solar+battery installation? what if your CPU wakes up and you have only a couple of hours of runtime? What if you only can turn on wifi for 20 minutes a day?

g8oz 3y ago
This sounds very interesting, please do write it up.

ranger207 3y ago

The only software that can go without updates is software that gets it right the first time If you're building software for yourself, this is relatively easy. Your tastes probably won't change that much even after a decade. You can probably ignore minor problems like using an O(n^2) function where there exists an O(n) because n is small. If you're writing software that other people will use, then that's where the problems come in. Other people don't have the same requirements as you, and may have a large enough N that the O(n) function makes it worth it, for example. But regardless of if you're writing for yourself or someone else, sometimes you just can't foresee problems. Maybe it crashes processing files larger than a gig, but because you've only ever used files <100KB it's never mattered to you. Then you go in to fix the crash and it turns out you're going to have to rewrite half the thing. This is, I think, the biggest argument against the idea that software that doesn't change is inherently better than software that changes frequently[0]: it may be that unchanging software was perfect from the first line, or it may be that there's terrors lurking in the deep, and a priori it can be difficult to tell which a particular project is. [0] This is not to say that rapidly updating software is inherently better than slowly updating software either. There's many factors other than just update speed

fauigerzigerk 3y ago
I don't think the idea is that software should never change. If requirements change then software obviously has to change as well. But over the course of 10 years a lot of things can change that have nothing to do with changing requirements. Open source projects are abandoned or change direction. Commercial software gets discontinued. Companies get acquired. App Store / Play Store rules change. APIs go away or change pricing in ways that render projects economically unviable. Toolchains, frameworks and programming languages, paradigms and best practices change. I think the point is that you don't want external changes that are unrelated to your requirements to force change on you. It's a good principle but as always there are trade-offs. There is stable and then there is obsolete. The difference is often security. And what if an important new requirement is easy to meet, but only if you bump a vendored library by seven major versions causing all sorts of unrelated breakage? What if there aren't enough people left who are familiar with your frozen-in-time toolset and nobody wants to learn it any longer? I think careful and even conservative selection of dependencies is a good idea, but not keeping up with changes in that hopefully small set of dependencies is one step too far for me.

secwang 3y ago

c , Common Lisp , apl All of these have a solid history of backward compatibility.

zubairq 3y ago

I had to read this article a couple of times before I got it. I guess dependencies can make an app warm blooded, but Docker or containerization can also paper over some of these issues. However, whenever I choose libraries for a project I do alot of research to make sure that the libraries themselves are "cold blooded" too, as even one badly chosen library can cause your project to fail in 10 years time

DeathArrow 3y ago

Cold blooded: random utility written in C 40 years ago. Warm blooded: random app using random Javascript framework, written 6 months ago.

kirillrogovoy 3y ago

One interesting thing about learning Elixir and its (+Erlang) ecosystem after 5+ years of JS/TS is that half of the most popular libraries seemed abandoned. However, when you look closer, turns out that most of them just finished the work within their scope, fixes all reproducible bugs, and there's just not much left to do. If there's a JS dependency with the last commit in 2022, it probably won't even build. (I'm half-joking of course, but only half)

sergiomattei 3y ago
I noticed this too and I’m still getting used to it.

pqwEfkvjs 3y ago

hot bloodedness ~= num dependencies

jviotti 3y ago

Great article. I try to follow this advice as much as I can. My personal website (https://www.jviotti.com https://www.jviotti.com) runs almost purely on well established UNIX tools like Make, Pandoc, Sed, etc. Repository here: https://github.com/jviotti/website https://github.com/jviotti/website.

deterministic 3y ago

I love cold-blooded software and avoid unstable-ever-changing software as much as possible. Why? Because I can then focus 99% on delivering customer value instead of constantly rewriting code that used to work just fine but now doesn’t because some inexperienced snowflake narcissistic developer decide to make arbitrary changes to an API that worked perfectly fine for years! Sorry a bit of a rant there. Unstable software makes me want to throw my PC out of the nearest window.