滨州软件开发的本质
文章作者：淄博软件开发 时间：2015年08月05日
软件的本质是什么？为了严密一点，滨州软件开发一般这么描述软件的本质：软件是一种固化的思维，这一点决定了许多的事情。从特质上来看，既然软件是固化的思维，那就必然同时具备思维以及思维所承载之物之特质。
思维的特质是指：思维的澄清通常是渐进的，思维自身是不可度量的，主体一定是人，通常由概念和逻辑组成，思维具有无边界化（灵活易变）这样的特质。这部分特质是共通部分，属于所有软件。
既然思维自身的特质是复合的，那么作为固化思维的软件，其特质必然也是复合的：既有属于所有软件的共同特质，也有特属于某类软件，甚至同其他类软件完全相反的独有特质。
这也就意味着在软件这一大的范畴里，两种矛盾的说法同时成立，并不是什么值得惊讶的事情。只要思维承载的东西蕴含着彼此对立的东西，那么两种对立的观点同属于软件这一范畴，并且同时争取，一点也不稀奇。这很可能是大家吵来吵去的一个根本原因，因为我们总是喜欢用自己的经历来定义软件是什么以及判断标准，但如果这种经历来自完全不同的两个领域，并且互相矛盾，那就只能吵架。实际上只有基于软件是一种思维这样特质推导出来的东西才更有普适性。
在什么时候对本质的思考会有用？简单来讲越是处理全局性、长期性问题的时候，对本质的认知就越能起点作用；而越是当即就要处理的工作对本质问题的思考，越没什么帮助。
比如：有个Bug让程序崩溃了，而程序明天就用，最好的方法可能还是赶紧调试，而不是思考什么本质。
但当我们要思考怎么让一个方法论落地更适合自己的时候，对本质的思考就能起点作用。比如始终会有公司尝试按Bug数和代码行来度量一个人的绩效。如果结合对本质问题的思考，一般来讲就不会做这类决定。
对人进行量化管理的基石是：量化后的数字主要受个人表现这一个因素的影响，否则将产生巨大的不公正，并对个人工作意愿产生不良影响，是真正的事与愿违。
滨州软件开发认为软件开发的输入是需求，对需求自身的复杂程度眼下来看还只能依赖判断，而不能精确度量，现实中并没有一种有效方法用以度量需求。软件开发的输出是代码，而代码自身属于固化后的思维。在度量思维时，多少、大小、长短、厚薄这类惯常的度量方向，并不具有多大意义。就好比说，不能讲一个人代码写的越多贡献就越大一样。
诚然思维的表现形式是可以度量的，我们可以通过页数来度量一本书的厚薄，通过分钟来度量一部电影的长短，通过代码行来度量软件，但这种度量所反映的内涵是有限度的，精度也是有限度的。最终结果很可能是人员之间的差距是由误差或其他非主观因素造成的，而不是由个人工作好坏所造成的。
总结来看，在软件开发中，数字含义的模糊性，会导致使用数字进行评价包含非常多的不公正，这种不公正会对工作意愿构成致命伤害，所以个人层面的量化管理在软件开发面前，几乎必然崩溃。
如果有这类思考和认知，想必做某些决定的时候，正确性会稍微提高一点吧。
具体来看：软件本质上是只有人才能处理的东西，因此公司中程序员群体的衰落一定会导致软件自身的衰落，只有优秀的程序员群体，才能保证软件的持久成功，这是必然性。但优秀的程序员却不一定确保当前项目成功，任何人在细节上的小疏忽，都可能导致软件在市场上崩溃，死锁，进而导致灾难性后果，这就是细节决定成败。
成败自身虽然万众瞩目，对个体而言却只是一种偶然和机巧。当事人可以很努力的平衡本质上的追求（长期视点）和细节上的追求（短期视点），但变更的始终是一种成败可能性。
