|
我们总是喜欢用自己的经历来定义软件是什么以及判断标准，但如果这种经历来自完全不同的两个领域，并且互相矛盾，那么就有可能让大家吵来吵去……是的，各位在忙于解决具体问题时，谁还会想到谈谈软件开发的本质？
看过我之前文章的人，可能会感觉到我对不加思考的所谓分享是持鄙视态度的，不管这种分享被冠以干货，经验或者随便什么名字。不是说这类分享没价值，而是说越是这类分享越适合具体问题，而不适合影响因素过多的事物，比如管理，比如文化，比如方法论，比如对软件本质问题的认知。
我们当然可以到StackOverflow上分享某个问题的具体解决方法，因为具体技术类问题只依赖于简单的上下文；但我们真的可以用一种简单问答的形式去解决管理、文化、方法论上的问题么，显然是不行的，这需要一种更系统的思考，也就是我之前经常提到的特殊到一般，一般再到特殊的过程。但在具体思考解决问题前，其实还有个事情要做，你要对问题的载体有所认识，对IT人，问题的载体几乎一定是软件，那么也就等价于需要对软件的本质有所认识。
这就是上面的题目的来源，在忙于解决具体问题的同时：谁还愿意谈谈软件开发的本质？
本质问题的思考往往不作用于当下，而只对未来产生潜移默化的影响，当然也可能没等产生影响，当事人就失去了所有机会。它的关键价值在于可以帮助一个人形成属于自己的方法论。软件是个很奇妙的东西，更像每个人都在横看成岭侧成峰状态的东西，所以很容易大家都自我感觉良好，看别人大大的不对，这时候要想不只局限在怎么解决一个Bug，就要思考一点本质的问题。
软件的本质是什么
为了严密一点，我一般这么描述软件的本质：
软件是一种固化的思维，这一点决定了许多的事情。从特质上来看，既然软件是固化的思维，那就必然同时具备思维以及思维所承载之物之特质。
- 思维的特质是指：思维的澄清通常是渐进的，思维自身是不可度量的，思维的主体一定是人，思维通常由概念和逻辑组成，思维的无边界化（灵活易变）这样的特质。这部分特质是共通部分，同时属于所有软件。
- 思维承载之物之特质是指：当思维的对象是数学的时候，思维本身也就具备了数学的特质；当思维的对象是商业逻辑的时候，思维自身也就具备了商业逻辑的特质。
既然思维自身的特质是复合的，那么作为固化思维的软件，其特质必然也是复合的：
既有属于所有软件的共同特质，也有特属于某类软件，甚至同其他类软件完全相反的独有特质。
---《完美软件开发:方法与逻辑》
这也就意味着在软件这一大的范畴里，两种矛盾的说法同时成立，并不是什么值得惊讶的事情。只要思维承载的东西蕴含着彼此对立的东西，那么两种对立的观点同属于软件这一范畴，并且同时争取，一点也不稀奇。这很可能是大家吵来吵去的一个根本原因，因为我们总是喜欢用自己的经历来定义软件是什么以及判断标准，但如果这种经历来自完全不同的两个领域，并且互相矛盾，那就只能吵架。实际上只有基于软件是一种思维这样特质推导出来的东西才更有普适性。
在什么时候对本质的思考会有用
简单来讲越处理全局性长期性问题的时候，对本质的认知越能起点作用；而越是眼下就用类型的工作对本质问题的思考越没什么帮助。
比如：有个Bug让程序崩溃了，而程序明天就用，最好的方法可能还是赶紧调试，而不是思考什么本质。
但当我们要思考怎么让一个方法论落地更适合自己的时候，对本质的思考就能起点作用。比如始终会有公司会尝试按Bug数和代码行来度量一个人的绩效。如果结合对本质问题的思考，一般来讲就不会做这类决定。
对人进行量化管理的基石是：量化后的数字主要受个人表现这一个因素的影响，否则将产生巨大的不公正，并对个人工作意愿产生不良影响，是真正的事与愿违。
好比说，不同的工人在同等条件下生产杯子，一个人一小时生产5个，一个人1小时生产6个，那显然后者要好于前者。这时，5和6可以用来比较的前提是两个人的生产条件相同，比如生产工艺等。在这种情况下，量化后的数字为个人表现的函数，因此量化管理基本上是公正的。
这时可以进一步来考虑下面的情形：两个人同时生产杯子，厂方安排一个人用工艺a，另一个人用工艺b，这个时候前者一小时生产5个，后者1小时生产6个。这个时候单纯比较5和6事实上是不公平的，因为这1个杯子的差距可能是工艺造成的。
大多时候，软件的情况比后一个情形还要糟糕一些。在软件开发中，往往既没有办法清楚的界定一个人的输入，也没办法清楚的界定一个人的输出。
软件开发的输入是需求，对需求自身的复杂程度眼下来看还只能依赖判断，而不能精确度量，现实中并没有一种有效方法用以度量需求。
软件开发的输出是代码，而代码自身属于固化后的思维。在度量思维时，多少、大小、长短、厚薄这类惯常的度量方向，并不具有多大意义。就好比说，不能讲一个人代码写的越多贡献就越大一样。
诚然思维的表现形式是可以度量的，我们可以通过页数来度量一本书的厚薄，通过分钟来度量一部电影的长短，通过代码行来度量软件，但这种度量所反映的内涵是有限度的，精度也是有限度的。最终结果很可能是人员之间的差距是由误差或其他非主观因素造成的，而不是由个人工作好坏所造成的。
总结来看，在软件开发中，数字含义的模糊性会导致使用数字进行评价包含非常多的不公正，这种不公正会对工作意愿构成致命伤害，所以个人层面的量化管理在软件开发面前，几乎必然崩溃。
如果有这类思考和认知，想必做某些决定的时候正确性会稍微提高一点吧。
本质决定成败还是细节决定成败
这世上同时存在着两种对立的声音：本质决定成败和细节决定成败。偏好本质的人喜欢说本质论。偏好细节的人则喜欢说精细化管理。但如果在较长的时间轴上考量这两种观点，就会发现他们之间并不真的对立。
本质决定大尺度时间上的走势和必然性，而细节则决定差异（包括短期成败）。比如说：人的本质特征是能思考，有一个头，会衰老，寿命有限等，但区别不同人却不是这些，而是性格，肤色，发色等细节。
具体来看：软件本质上是只有人才能处理的东西，因此公司中程序员群体的衰落一定会导致软件自身的衰落，只有优秀的程序员群体，才能保证软件的持久成功，这是必然性。但优秀的程序员却不一定确保当前项目成功，任何人在细节上的小疏忽，都可能导致软件在市场上崩溃，死锁，进而导致灾难性后果，这就是细节决定成败。
成败自身虽然万众瞩目，对个体而言却只是一种偶然和机巧。当事人可以很努力的平衡本质上的追求（长期视点）和细节上的追求（短期视点），但变更的始终是一种成败可能性。
| 
