It Can Be Done (2003)
关于 André Bensoussan 完全在纸上设计了一个复杂的 Multics 文件系统组件的轶事，引发了一场更广泛的讨论：软件曾经是如何——以及在何种条件下仍然可以——在深度专注、清晰需求和极少工具的情况下构建出来的。评论者将那个时代安静的办公室、小而概念上复杂的系统，以及强大的领域掌握能力，与如今被打断驱动的工作流、在“敏捷”名义下不断变化的规格，以及文档混乱的庞大依赖栈进行对比。许多人认为，谨慎的前期设计、与领域专家的紧密协作，以及书面的设计文档，都是被低估的技能，即使当年迫使人们保持这种严谨的约束如今已不复存在，它们仍然能显著提升现代软件质量。
笔纸编程与历史背景
- 很多人回忆起在电脑使用极其有限的情况下学习或工作（纸张、穿孔卡、长达一周的编译周期）。
- 这迫使人们进行更谨慎的推理、减少反复迭代，并且常常导致代码在第一次运行时就能工作。
- 几位评论者认为，Multics 的故事属于更广泛的“量两次，切一次”时代，当时计算时间稀缺，终端也不会分散注意力。
- 也有人指出，这种环境可能还起到了筛选作用：只有极具动力的人才能在这些约束下坚持下来。
需求、边界情况与不断变化的规格
- 大家普遍认为，清晰、稳定的需求和定义明确的 API 让高质量代码更容易实现得多。
- 现代问题包括：目标模糊、利益相关方反馈太晚、范围不断变化却被标成“敏捷”，以及对截止日期和“速度”的压力。
- 关于 agile 的争论：有人说它是对不可避免的需求变化的回应；也有人说它使持续变动正常化，并鼓励不负责任的改动。
- 边界情况是 bug 和复杂性的主要来源。有人认为罕见情况应该手动处理；也有人说在大规模下，即使 1% 也会影响数百万人，必须通过工程化来解决。
设计、文档与在编码前思考
- 几位评论者强调，能够把问题和拟议方案写下来，是真正理解的标志。
- 简短的设计文档和图示被视为思考工具，而不是官僚主义。
- 有些人觉得很难在纸上设计，声称他们只有在打字和反复迭代时才能理解系统；另一些人则认为这是一种可以训练的技能。
- 测试驱动开发被建议为现代版的“先设计后实现”。
领域专长与工程思维
- Multics 这项成就之所以可能，一个关键原因是这位程序员本身也是一位深度领域专家。
- 很多人认为，真正的价值在于理解问题领域并塑造需求，而不只是把规格翻译成代码。
- 有人担心，许多现代开发者缺乏全栈理解，把性能和健壮性当作事后再考虑的问题。
工作环境、规模与情绪反应
- 过去的环境：安静的独立办公室、大桌子、没有通知、管理层也懂技术。
- 如今：频繁打断、会议、工具泛滥，以及日益增长的互联系统和外部 API。
- 有些人受到启发并怀旧；另一些人则持怀疑态度，指出现代复杂性和混乱的集成让“一次通过就完美”变得不现实。
- 一个反复出现的感受是：许多开发者觉得自己没有被充分利用，只是在做低影响的 CRUD/广告工作，而不是基础性系统，这导致了挫败感和犬儒主义。