人月问题的原因在于软件的如下本质
“一个相互牵制关联的概念结构，是软件实体必不可少的部分，它包括：数据集合、数
据条目之间的关系、算法、功能调用等等。这些要素本身是抽象的，体现在相同的概念构架
中，可以存在不同的表现形式。尽管如此，它仍然是内容丰富和高度精确的。
我认为软件开发中困难的部分是规格化、设计和测试这些概念上的结构，而不是对概
念进行表达和对实现逼真程度进行验证。当然，我们还是会犯一些语法错误，但是和绝大多
数系统中的概念错误相比，它们是微不足道的。
如果这是事实，那么软件开发总是非常困难的。天生就没有银弹。”
这个本质可以和中子链式反应做个类比
中子 ->中子链式反应-->原子弹爆炸
概念 ->互相牵制关联 -->复杂度爆炸
这只是核心概念复杂性，再结合具体工程技术，组织分工等依赖关系影响，其复杂性将要更复杂的多。
一个陷入焦油坑的项目，无论增加还是减少资源，都极大可能变得更糟。其根本的原因在于各种牵制关联梳理的不够清晰；减少或者增加会导致额外的变化。
而一个正常的项目，未必是完全清晰的，但至少不清晰的部分尚未暴露到方案或者工程团队面前，因此无论增加或者减少人手，其影响都至少是可以预见和控制的。
《人月神话》一书宣称没有银弹。然后原子弹爆炸式不可控的么？
是可控的。那么同样的，软件的复杂性也是可控的。机制和原理是类似的
1，降低发生反应的中子 vs 减少概念数量
2，减少发生关联 vs 减少关联和耦合依赖
3，隔离中子 vs 隔离变化，或者转化变化
12的有效办法是抽象，合理的抽象，3的办法是模块化，引擎化
进一步，有什么办法能控制次要复杂性呢？
1，采用简单的技术方案
2，手术刀团队——职责单一，分工明确，协作成本低的团队
一句话：低熵工程方案和低熵组织结构
网友评论