Cold-blooded software (dubroy.com)

Article summary

The article discusses the concept of 'cold-blooded software', which refers to software projects that can survive without constant maintenance and updates, much like cold-blooded animals can adapt to changing temperatures. The author argues that using 'boring technology' and avoiding external dependencies can help create such projects. The author shares their personal experience of creating a static site generator that has remained functional for over a decade with minimal updates. This approach is contrasted with 'warm-blooded software', which requires constant activity to stay viable.

Main themes

• cold-blooded software
• maintenance and updates
• dependencies and fragility
• technology choice and trade-offs
• project planning and time horizon
• security and reliability
• software longevity and archival

What commenters say

• Some argue that cold-blooded software is suitable for low-impact projects, but not for high-stakes applications where security and reliability are crucial.
• Others believe that using simple, tried-and-tested technologies can be beneficial for projects with high business impact, as it reduces the risk of dependencies breaking or becoming outdated.
• A few commenters suggest that the concept of cold-blooded software is related to the 'Buxton Index', which measures the time horizon of an entity's plans.
• Some argue that using small dependencies, like HTMX, can be a good compromise between maintaining a project and avoiding the complexity of larger frameworks.
• Others disagree, arguing that even small dependencies can introduce fragility and breaking changes, and that using vanilla JavaScript and avoiding dependencies altogether is a better approach.
• There is a debate about the trade-offs between using established frameworks and libraries, which may require frequent updates, and using simpler, more stable technologies that may require more manual effort.
• Some commenters note that the perception of a library's quality is often tied to its recent activity, but that stable, archived projects can still be valuable and reliable.
• Others argue that the ability to maintain a project over time is not just about the technology used, but also about the project's goals, scope, and the team's expertise and priorities.