软件中的Lindy effect
摘要
讨论了软件中的Lindy effect,认为经过长时间验证的旧技术通常比新潮技术更可靠且风险更低。
暂无内容
查看缓存全文
缓存时间: 2026/07/11 07:23
# 软件中的林迪效应
来源:https://www.clemsau.com/posts/the-lindy-effect-in-software/
一件衣服流行的时间越长,就越有把握说它会持续流行下去。
同样地,如果一本书在过去几十年或几个世纪里一直被阅读,那么它不太可能很快过时,尤其是与更近期的书籍相比。
这些现象可以用一个我深感着迷的理论来解释——林迪效应。这个概念表明,某样事物存在或存活的时间越长,它未来继续存在或存活的预期时间就越长。
## 软件中的林迪效应意味着什么?# (https://www.clemsau.com/posts/the-lindy-effect-in-software/#what-does-the-lindy-effect-in-software-could-mean-)
将其应用于软件,可能意味着:一项技术存在的时间越长,它可能就越稳健,因此与近期流行的技术相比,押注它更明智。
是的,我明白,软件在人类历史中并不古老,至少不像钟表或书籍那样古老。硬件和软件都在不断进化,这很棒,我们显然也要拥抱变化(那些新的 Apple Silicon 处理器确实非常出色)。
但这并不意味着那些带来突破性基准测试的新技术就是你应该将全部应用迁移过去的目标——显然不是。
说得更明确些,当你选择平淡的技术(https://boringtechnology.club/)时,你获得的益处包括以下几点:
1. **稳定性和可靠性**:经受住时间考验的较老技术和编程语言通常提供更高的稳定性和可靠性。多年间,错误和漏洞已被发现并修复,使其成为关键应用的更稳健选择。
2. **成熟的生态系统**:成熟的技术通常拥有完善的生态系统,包括丰富的文档、库和社区支持。这些资源对软件项目来说非常宝贵,能简化开发和故障排除流程。
3. **可预测的性能**:较老的技术已在众多真实场景中经过实战检验,其性能特征更具可预测性。在构建要求严格的系统时,这种可预测性至关重要。
4. **行业接受度**:经历了时间考验的技术通常享有广泛的行业认可。这意味着精通这些技术的专业人员更容易找到,从而简化了使用这些成熟工具构建和维护软件的过程。
5. **降低风险**:技术的新颖性伴随着固有风险,例如未发现的错误、可扩展性挑战或不确定的长期支持。较老的技术有经过验证的记录,能降低与追逐最新潮流相关的潜在风险。
软件中的林迪效应:一项技术存在的时间越长,与较新的技术相比,它就越被视为稳健。我们常谈论技术的成熟度。C 语言、SQL 已经存在了相当长的时间,https://antonz.org/fancy-ql/,而 JS 库似乎在不断更迭。
我个人倾向于在企业级后端中使用 Go 而非 Java,但我理解大型软件公司为何会选择后者作为最稳妥的赌注——他们已经在 Java 上使用了数十年。
SQL 自 1989 年以来一直存在,而且短期内不会离开我们(至少,在你读到这篇文章时,我希望它还在)。
C 语言本身诞生于 1972 年,到 2023 年仍有人在用,这让我对它随时间推移的相关性充满信心,无论其他底层编程语言是否兴起。
## 将林迪效应应用于软件工程# (https://www.clemsau.com/posts/the-lindy-effect-in-software/#applying-the-lindy-effect-to-software-engineering)
这个概念对软件工程师来说可能会很方便,帮助他们找到采纳新技术与拥抱经过时间考验的技术之间的平衡。将这一原则融入开发过程的一些实际步骤可能包括:
1. **谨慎采纳**:在将新技术引入项目之前,仔细评估它们。考虑技术的潜在收益、风险和长期可行性。
2. **坚持成熟基础**:依赖成熟的技术和最佳实践来构建软件的核心组件。这些基础将为你的应用提供稳定性和可靠的支撑。
3. **规划长期性**:在设计软件架构时,考虑技术选择对项目长期可行性的影响。优先考虑可维护性、兼容性和可持续性。
4. **拥抱演进,而非革命**:与其不断重写或彻底改造你的软件,不如随时间推移逐步改进和更新它。渐进式变革通常更易于管理,也不易引入重大问题。
相似文章
慢速软件:为高延迟系统开发辩护
文章认为,AI编程加速了开发速度与系统重要性的脱钩,导致关键系统变得脆弱且故障波及范围广,并倡导实施强制谨慎设计的‘慢速软件’。
选择无聊技术与创新实践
文章认为,团队应选择无聊且已被充分理解的技术以确保可靠性,同时可以在开发实践上自由创新,比如TCR(测试&&提交||回滚),这些实践更易于采纳和放弃,没有长期维护负担。
软件在没有形式化证明的情况下如何变得如此可靠?(1996年)
这篇1996年的论文探讨了尽管缺乏形式化证明,软件可靠性却日益提高的原因,讨论了非正式方法和工程实践。
为何低延迟Java仍需严谨的编码纪律?
讨论为何在现代JVM优化下,低延迟Java仍需严谨的编码实践。
快速软件,最佳软件
一篇论述快速软件对用户信任与满意度至关重要的文章,通过nvALT和Ulysses等示例,阐明了速度的优势以及缓慢的弊端。