No silver bullet
#
- https://aistudio.google.com/prompts/1AsNqJqI66og4GWJig9l5o35NX1gw8-l5
- 发表于 1986
- 核心的观点是：未来十年没有任何工具可以让软件的生产率/可靠性/简洁性提升一个数量级，或者说未来软件工程的提升必定是渐进的、持续的
- 软件的 difficulty 分为两类：essence 和 accident，分别代指软件本性带来的困难和工具/硬件带来的外部限制
- 软件工程的本质困难包括四个特征
- complexity: 软件的元素数量的增多带来的复杂度提升是指数速度的，并且不像自然科学一样可以寄希望于大统一的简化规律
- complexity 是软件的本质，软件本身就是问题 complexity 的体现
- complexity 会导致穷举/扩展/使用上的困难，以及不可见的漏洞
- conformity: 软件需要适应复杂的需求和现存的规范
- changeability: 和硬件不同软件可以被修改，所以往往承受修改和扩展功能的压力
- invisibility: 软件缺乏单一和直观的可视化表达，阻碍了设计和沟通
- 过去的一些进步解决了 accident 性质的困难
- 高级语言带来了大幅度的生产力提升，程序员不需要再去关注比特、寄存器等底层问题
- 分时系统取代 batch 处理，使得快速迭代、即时响应成为可能
- 统一编程环境（比如 Unix/Interlisp）解决了程序之间协同的问题
- 未来的一些可能的 silver bullet 包括
- Ada 语言
- OOP：去除了表达过程的一些困难，允许更高层次的表达，不需要不必须的类型声明
- AI
- AI-1 指的是用计算机完成之前人类的工作，比如语音识别/图像识别
- 不存在一种通用的 AI magic 可以移植到软件开发中
- 软件工程本质的困难不在于表达（而是构建表达的内容），所以任何改进表达方式的工具都不会有很大收益
- AI-2 expert systems 定义为接收输入数据和假设条件、推导逻辑结果、提出结论和建议的系统
- 专家系统由一个通用推理引擎和一个 rule base 组成，应用本身的复杂性被加入 rule base 中
- 可以将顶尖程序员的经验法则传授给新手，但是不会有革命性突破
- 专家的隐性知识也不一定能很好地提取出来
- 自动编程：无法推广
- 图形化编程：软件无法很好地展示到二维平面上
- 程序验证：只能证明程序符合 specification，但是得到一份 specification 也是很难的事情
- IDE, database
- 作者认为解决 essential 困难的途径是
- 购买而非构建：在可能情况下选择直接使用现成软件
- 需求精炼和快速 prototype：用户其实无法描述自身需求，所以需要通过迭代来提取/优化产品需求
- incremental development: 采用 top down 的顺序开发软件，先定义骨架再填充血肉，每次为现有结构填充新的功能
- 培养卓越的设计师：好的软件更快、更小、更简单和清晰
Refired
#
- https://aistudio.google.com/prompts/10QdfclRpJ4VVm4xIjaaXSVEzX5h9g8Vn
- 发表于九年之后 1995
- 作者 claim 如他所预期的那样过去十年没有出现 silver bullet
- 核心的原因：那些「概念性结构的精确和有序表达」的努力已经降低到了总工作量的一半，只要它占据 90% 以下那么任何对于这一部分的提升都不会对软件工程本身起到一个数量级以上的提升效果
- Cox 认为困难来自程序员现有的开发方式
- 物理学家认为软件可以找到理顺复杂性的通用法则，类似用热动力学研究分子运动
- 解决本质复杂性的办法是分层化（module, object）和 incremental development
- Harel 的文章认为 nsb 是一篇悲观的文章，并且如果放到 1952 年结论显然是错误的
- 提出了一种 silver bullet 是视觉形式化的编程技术
- 作者的反驳：软件的逻辑/结构无法用存在于三维空间中的物体描述
- Capers Jones: 应该将关注重点放在质量上，很多时候软件的生产率受到质量的拖累
- buy don’t build 在 1995 年看来是一个趋势，典型例子是 MS office
- 大家普遍认为 OOP 可以成为一个 brass bullet
- 作者的观点是 OOP 需要前期巨大的投入，在后续扩展/维护/重用阶段才能体现出收益和效率
- reuse 也是一个解决困难的路径，但是很少人使用
- 相比之下数学领域 reuse 广泛的原因在于每行代码的（智力）成本很高，而且数学语言非常标准
- 软件工程中的库数量太多会导致学习过程非常漫长
- 软件开发的本质是解决 complexity，这是软件开发效率的上限
- 作者的希望是让人们把精力放在可行的、渐进的、现实主义的改进方案，而不是革命性突破的 silver bullet 上面
Propositions of the mythical man-month: true or false?
#
After 20 years
#
- https://aistudio.google.com/prompts/1oYmEkl4V19YVadSgIQKASsH8BnY65wk0
- 硬件制造的生产率提升使其由劳动密集转向了资本密集，但是软件开发仍然本质上是劳动密集的
- 关于概念完整性：一个干净优雅的软件应该向用户呈现一个连贯的 mental model，这就要求了软件必须由一个（或极少数）人来统筹全局，并且将实现和架构相互分离
- 包含众多用户的软件的设计开发非常困难，因为需要平衡多样化的需求，有时候会因为添加边缘功能牺牲性能/简单性
- 过去 20 年最重大的胜利是 WIMP (windows, icons, menus, pointing)
- 主要的进步是让操作变得更加符合直觉
- 鼠标点击 icon 和键盘操作 menu 分别对应于每个动作中的 noun 和 verb 组分
- 「准备好抛弃第一个系统」仍然带有瀑布式开发的弊病，最好的做法是建立 mvp/prototype 然后 incrementally 填充内容
- MS Windows 将其做到了极致，每天增加一个小功能
- 作者被 Parnas 说服对 information hiding（模块应该被封装，对其他人不可见）表示赞同
- 对 peopleware 这本书提出了表扬：工作中的主要问题并不是技术问题而是社会问题
- team fusion 非常重要
- 大型组织应该将权力和责任下放到基层团队
- 过去 20 年最大的变化是 PC 的普及以及现成套装软件的崛起
- 「在现成软件的基础上进行开发」是一个解决复杂性问题的 promising 途径
- 软件工程仍然面临的主要问题是：如何在巨大的体量下保持对复杂度的智力控制
Thoughts
#
- 这里对 AI 的看法值得详细阅读：现代 LLM coding agent 提升的部分是做事，而不是设计
- gemini: LLM 是高级编程语言发明以来最强大的一颗 lead bullet
- LLM 是 ultimate/perfect AI-2，「极大地甚至近乎彻底地清除了软件开发中残存的偶然属性」
- 在完整的软件生命周期中，程序员编写代码的时间一般仅占 10%-20%，其余的时间用于理解需求、设计系统架构、配置环境、debug 等
- 「概念性结构的精确和有序表达」的过程现在已经完全被 AI 解决，相比之下「将模糊的需求/想法转化为概念/spec」的 essential difficulty 确实是主要的困难