Infoworld 特约撰稿人 Nick Hodges 发布了一篇名为“Four paradoxes of software development”的文章，阐述了他眼中的软件开发领域的四大悖论。
全文内容如下：
桥梁建设 vs 软件开发：四个令人困惑的悖论
土木工程师可以理直气壮地说，世界上没有两座完全相同的桥梁。然而，桥梁共享许多已知特性，其建筑材料也有明确参数。桥梁建设涉及大量已知的已知项，未知的未知项远比人们想象的少得多。
我并非土木工程师，对设计和建造桥梁的杰出人士充满敬意。但我想通过这种对比说明：编写优秀、可运行的软件极其困难。软件开发团队承接的每个项目都是独一无二的。尽管项目之间存在相似性，但每个软件项目都有其独特的细微差别、需求，以及大量的未知未知项。
或者说，软件开发充满了难以处理的悖论。以下是四个典型案例：
悖论一：无人知晓工期，但客户坚持要交付日期
坦率地说，这可能是软件开发组织面临的最大挑战。我们根本无法确定任何项目需要多长时间。当然，我们可以估算，但结果几乎总是大错特错——有时严重高估，但更多时候是严重低估。
对客户而言，这既神秘又痛苦。由于不理解悖论的第一部分，他们不明白为何无法确定新软件的交付时间。当软件未能如期交付时，挫败感自然产生。
我们尝试使用 story points、planning poker和其他敏捷方法来预测进度，但始终无法摆脱霍夫施塔特定律（Hofstadter’s Law）的魔咒：即使考虑了霍夫施塔特定律，事情总会比你预期的更久。
悖论二：向延期项目加派人手，只会让项目更晚
这条被称为布鲁克斯定律（Brooks’s Law）的规则，对旁观者而言可能是最诡异的悖论。
通常，如果你发现无法按时完成牙膏管灌装任务，可以通过增加人手来赶上截止日期。如果你想在一年内建造双倍数量的房屋，通常只需双倍投入劳动力和材料即可实现（误差很小）。
然而，正如弗雷德·布鲁克斯（Fred Brooks）在其著作《人月神话》中所揭示的：“向延期的软件项目增加人力，只会让它更晚。” 这是一个悖论，却是软件开发领域最接近定律的真理。布鲁克斯指出，新成员需要时间理解复杂系统的上下文，并增加沟通成本，因此无法立即贡献生产力——这反而会延长项目周期并推高成本。
悖论三：编码能力越强，编码量反而越少
成为一名经验丰富的软件开发者需要多年积累。学习正确的编码方式、设计方法，以及编写整洁可维护代码的规则与技巧，绝非一日之功。
但讽刺的是，随着经验增长，你往往会被推向领导岗位，实际编码量反而减少。你不再写代码，而是参加设计会议、审查他人代码、管理团队。有时，你甚至因晋升而彻底告别编码。
这并不意味着资深开发者的贡献减少。通过规划项目、指导新人、维护编码标准，并确保团队产出优质代码，资深开发者对团队和公司的成功至关重要。
但你的确会写更少的代码。
悖论四：开发工具日益强大，但开发效率并未提升
对比当今使用React、Astro、Next.js等强大工具构建的Web应用，与30年前通过通用网关接口（CGI）处理数据和 HTML 的网站，你会发现我们已经比早期进步了数光年。
然而，尽管工具日益先进、处理器速度飙升，软件开发效率似乎从未真正提高。工作量不仅总是超出时间预算，甚至超出了每个 CPU 周期的负荷。
我们的网站更美观了，但开发效率真的提升了吗？网站运行更快、数据处理更高效了吗？诚然，新框架和库抽象了许多复杂性（还有人想写jQuery代码吗？），但它们也带来了构建流程冗长、配置复杂、依赖膨胀等新问题。
与桥梁的终极差异：软件永无“完工”之日
这些悖论的存在并不意味着绝望。我指出它们，是为了让我们意识到其存在，学会接受并应对，从而避开潜在的陷阱。我们无法消除软件开发的陌生感和混乱，但可以预见并驾驭它们。我们的使命是：在悖论中交付。
最后一个悖论或许是：软件开发永远没有真正完成之日。总有新功能可以添加。而桥梁工程至少有一个明确的终点——当桥梁建成并按设计运行时，工作便宣告结束。