人月神话。为什么一个软件项目，程序员越加越多，反而越容易延期？这就是软件工程经典《人月神话》最重要的结论。很多管理者有一个直觉：1个人做12个月，是12人月；那12个人做1个月，也应该是12人月。但软件开发不是搬砖。因为软件项目除了写代码，还有大量的沟通、培训、协调、测试、集成和返工。2个人只有1条沟通关系；5个人有10条；10个人有45条；20个人就有190条。人一多，沟通关系会快速增加。所以，布鲁克斯提出了著名的“布鲁克斯定律”：向一个已经延期的软件项目增加人手，只会让它更加延期。为什么？因为新人加入后，老员工不但要继续开发，还要培训新人；新人又需要理解代码、业务和架构。与此同时，团队之间的沟通成本越来越高。更关键的是，软件真正困难的地方，并不是写代码，而是控制复杂性。软件复杂性可以分成两类：第一类是本质复杂性，比如业务规则、系统状态、模块关系，这些天然存在。第二类是偶然复杂性，比如低效工具、糟糕代码、落后的开发流程。AI Coding、IDE、自动化测试、CI/CD，都可以降低这一部分。所以AI时代真正稀缺的能力，不一定是“写代码”，而是：定义问题、设计架构、拆解复杂性、建立接口、组织团队、完成系统集成。《人月神话》还有一个重要观点：一个优秀的软件应该具有“概念完整性”。也就是说，整个系统最好拥有统一的设计思想，而不是几十个人各自发挥，最后拼成一个混乱的系统。所以真正厉害的工程师，不是单纯写代码最快的人，而是能够让复杂系统变得简单、清晰、可协作的人。一句话总结：人月不是生产力，架构才是杠杆；控制复杂性，才是软件工程真正的核心能力。人月神话