这是鼎叔的第十五篇原创文章。
行业大牛和刚毕业的小白，都可以进来聊聊。
欢迎关注本人专栏和微信公众号《敏捷测试转型》，大量原创思考文章陆续推出。
这篇展开聊聊畅销 40 多年的《人月神话》中的核心观点和个人启发。
软件工程效能到底有没有银弹？
神话中，银弹就是可以让强大的狼人被一击毙命的武器。
这里的银弹，指的是一招制敌，提高数量级的效能水平，而不只是效能有明显改观。
这个话题在业界激烈讨论了几十年，普遍倾向的结论就是 -- 没有！
可以逐步改进，但不能成十倍的改进。
换句话说，如果有某个效能专家，说他的方案可以让你的研发团队取得脱胎换骨的成果，基本上就是个忽悠了。
下面来逐步剖析原因。
软工工程的固有难度
系统级软件产品和单一任务不同，和硬件产品也不同。
写一段可工作代码很容易，做一个编程产品，就困难了好几倍，因为你要定义接口，处理输入的范围，需要让人可理解的编程风格和设计文档，最后要进行彻底的测试。
从一个软件产品到一个系统产品，复杂度又提高了几倍。因为你要考虑可以和它交互的各种程序的集合，还要考虑接口规范和响应性能，还有系统资源的资源限制，比如内存，IO，硬件兼容性。对应的系统测试时间更是成倍增加。
“人月” 的概念误导
项目经理最喜欢做的报表，充斥着 “人月”- Man-Month 的统计指标，咋一看很容易让老板理解项目需要的资源，以及当前的进度还差多少。
技术人员在估算方面往往便乐观，项目方也不会给足够的时间矫正估算，当意识到进度偏差时，关键矛盾就出现了-
从外部增加人手，可以追赶上进度么？
从项目的真实数据统计来看，不行。就算进度最终追上了，付出的 Man-Month 远远超过预估的资源缺口。
疲于奔命的大型软件项目，就像一个焦油坑，项目经理投入的工程师越多，在坑里挣扎得越厉害，无力自拔，于事无补。
究其原因为何？
“人” 和 “月” 不是一个可以互换的概念，除非人和人完全不需要进行交流。大多数任务都不是可以并行的，人们直接协作交流的成本和人数的平方成正比。另外，新人加入项目需要一定的培训时间。
软件产品因为有激烈的时效竞争，不太接受过慢的交付周期。而向进度落后的项目额增加人手，只会使进度更加落后。悖论在此。
项目的进度偏差也不是一下子出现的，它来自于每一天的滞后，或者对其他人员进度的不信任。
一线经理出于利益本能，不愿意让老板看到计划的偏离，而是尝试独立解决问题。
正确的做法建议是：老板应该减少发号施令的压迫感，把行为控制在 “状态检查” 和 “问题行动 “层面，也许就可以顺利地拉开（藏着污垢的）地毯。
高效的开发团队
就像一个外科手术团队，主刀医生（首席程序员/架构师）为主角，他专注于系统的思考设计，和成员的协调一致。其他的专业角色各司其职，彼此的交流简单直接，尽可能降低慌乱交接带来的高昂代价。
实现软件的易用性，本质上要设计出概念的完整性，对于复杂系统，这工作只能由很少数架构师完成，他们是用户利益的代言人，也是团队纪律的创建者。当各个工程师担负的功能实现可以和架构师的概念设计同步进行，个人创意反而可以顺利落实。
设计规范手册有利于规范大家的实现（降低沟通成本），建立缺陷排查日志，少量且关键的文档是至关重要的。
开发人员不愿意编写设计文档，通常并非是没有时间，而是不想把自己的思路暴露在大家的批评之下。
开发人员也不太喜欢画流程图，这是合理的，优雅的程序本身可以取代繁琐的流程图，程序即文档。
最后，高效的开发组织，也需要让技术专家获得不低于同级别管理人员的薪酬和福利。
设计的质量
软件在最初开发时，都是减少熵（减少混乱）的过程，在后期维护时，就变成了增加熵（增加混乱）的过程，这是所有软件的宿命，再好的维护也就是延缓软件退化到不可用的周期。
因此，架构师要学会基于变更而设计实验性的产品，如果发现用户对这个产品并不满意，要能够有计划地抛弃原型开发。开发人员交付的是用户满意度，而不仅仅是有形的产品。
如果我们在开发之前，能提交测试规格说明给专职的测试小组，那么产品的完整性和明确性就能得到详细检查。
在系统测试时，使用已完成充分调试的组件，会节约更多的时间。鼓励声明 “已知 BUG”，把还未修复的 BUG 带来的后果告知大家，以便仅聚焦解决新出现的问题。
另外，在变更控制上，和各种敏捷研发理论一致：有专人负责配置管理，隔离出变更范围（变化模块），每次增加一个组件，量子化提交独立变更，等等。
最后，回答--为什么没有银弹？
这么多年来，不管工程技术如何进化，银弹并没有出现的迹象。
我们要把软件工程的困难，分类为根本困难，和次要困难。前者是软件特性中固有的，后者是生产中出现的，但并非与生俱来的麻烦。
根本困难来自于概念结构，而不是如何验证细节：
一，复杂度。
没有两个软件是部分相同的，即使有相同代码也会被合成子函数。而硬件，建筑，汽车等行业则不同，存在大量重复的部分。软件系统的内部状态特别复杂，导致设计和测试难度非常困难。软件扩展添加了不同的元素实体，导致交互数量非线性增加。软件的复杂度和数学，物理完全不同，后者是研究模型简化的特征。
复杂度带来一系列核心麻烦，无法规避：沟通，成本，可靠性，拓展难度，安全隐患。
二，一致性。
工程师没有办法从科学信念中得到安慰，他面对的很多复杂度是随心所欲的，或者是人为制定的惯例，还需要保持各接口之间的一致性。
三，可变性。
软件实体经常要持续变更，类似变化在工业制造产品出厂后发生的概率小得多。因为软件修改成本要低得多，再叠加大量新用户的不同想法，就面临频繁扩展的压力。另外，软件总是在一定硬件上开发的，硬件变化也带来软件适配的变化；软件总是处于一定的用户文化圈的，文化在持续变化，也就无情地强迫软件发生变化。
四，不可见性。
软件是不可见的，无法可视化，因此阻碍了思路的交流。不像建筑图纸和分子模型，后者有几何抽象模型。
次要困难的解决则是富有成效的，确实带来工程效能在特定任务上的巨大效率。比如高级语言，分时处理，可视化编程，人工智能和专家系统等。
但纵观这些次要困难，解决的是具体 “如何做” 的问题，但无法解决 “做什么” 的问题，起到的只是促进作用。这些解决系统把具体应用的复杂度和实现程序做了分离处理。
我认为以上这一大段论述是软工工程理解上的经典思考，国内这二十年，不论技术工具更新了多少代，硬件强大了多少倍，准确定义一个知名产品依然是异常复杂的，几乎不可能的任务。从 QQ 到微信，从优酷到抖音，业务团队的规模从来没有明显下降，加班也没有明显减少，哪怕做的功能大同小异。
既然没有银弹，我们现在还能做什么？
虽然工程效能没有真正的捷径，但是显著提升效果的方法还是层出不穷的。不要把软件工程想象为 “巨无霸”，而是想象成 “微生物的世界”，没有一蹴而就，只有踏踏实实的尝试。
一，找到最优秀的架构师，让他负责整体的架构概念完整性。卓越的设计人员能带来优秀十倍以上的创造力。
二，尽可能购买第三方软件，尽量减少自行开发。商业软件包的增长，主要是因为硬件成本的大幅下降，导致为硬件定制软件的动力大幅下降。
三，引入需求精炼和快速原型工具，让客户尽快知道自己想要啥，概念上达成一致。产品原型就应该不断地被优化规格。
四，增量开发，让系统增长起来，而不是一步搭建到位。
从上可见，人月神话和敏捷观念非常一致，这也是敏捷教练圈会推荐这部经典作品的原因吧。
最后一个启发- 工程师的 35 岁悖论
这个热门的 “操心” 话题其实不值一驳。行业的观点很明确了，不论新语言，新工具如何发展，软件工程的本质效能不会突飞猛进。所谓 35 岁担忧，主要是说工程师年纪大了，学习新产品，新工具和新语言的速度弱于年轻工程师，且不论这个理由是否成立，但熟悉新技术新产品，从来不是软件从业者的核心价值。
能不能找到软件概念的本质，并帮助大家达成理解一致，拥抱敏捷的实践态度，这些才是关键，而这些都需要长期思考和经验的积累。