恰如标题，第二定律表示为：在思维可以精确量化前，量化管理在程序员身上永无可能。
这次估计会有争议，所以这里给出具体的逻辑链以及对应的分析。
逻辑链：
软件是一种固化的思维
具体分析：
公平公正是管理的基石，为达成这一目的很多人会想到量化管理，但量化管理的基石却往往被忽略。
对人进行量化管理的基石是：量化后的数字主要受个人表现这一个因素的影响，否则将产生巨大的不公正，并对个人工作意愿产生不良影响，是真正的事与愿违。
好比说，不同的工人在同等条件下生产杯子，一个人一小时生产5个，一个人1小时生产6个，那显然后者要好于前者。这时，5和6可以用来比较的前提是两个人的生产条件相同，比如生产工艺等。在这种情况下，量化后的数字为个人表现的函数，因此量化管理基本上是公正的。
这时可以进一步来考虑下面的情形：两个人同时生产杯子，厂方安排一个人用工艺a，另一个人用工艺b，这个时候前者一小时生产5个，后者1小时生产6个。这个时候单纯比较5和6事实上是不公平的，因为这1个杯子的差距可能是工艺造成的。
大多时候，软件的情况比后一个情形还要糟糕一些。
在软件开发中，往往既没有办法清楚的界定一个人的输入，也没办法清楚的界定一个人的输出。
软件开发的输入是需求，但同一个需求不需要做多次，所以对需求自身的复杂程度眼下来看还只能依赖判断，而不能精确度量。
软件开发的输出是代码，而代码自身属于固化后的思维。在度量思维时，多少、大小、长短、厚薄这类惯常的度量方向，并不具有多大意义。就好比说，不能讲一个人代码写的越多贡献就越大一样。
诚 然思维的表现形式则是可以度量的，我们可以通过页数来度量一本书的厚薄，通过分钟来度量一部电影的长短，通过代码行来度量软件，但这种度量所反映的内涵是 有限度的，精度也是有限度的。最终结果很可能是人员之间的差距是由误差或其他非主观因素造成的，而不是由个人工作好坏所造成的。
总结来看，在软件开发中，数字含义的模糊性会导致使用数字进行评价包含非常多的不公正，这种不公正会对工作意愿构成致命伤害。所以个人层面的量化管理在软件开发面前，必然崩溃。
补充说明：
- 为避免矫枉过正，最后需要强调的是：并不是说项目管理中不需要收集数据，只是说在软件这个行业中，各种数据的精度天生是有限的，因此必须用在允许有限精度的工作上（估算、任务安排等），而不能用在对人进行评价、对项目进行评价这样需要高精度数据的工作上。
- 这条定律的推论可以无限多，影响到管理，流程乃至估算，这里就不列了。