赌大小

 找回密码
 立即注册
搜索
热搜: 活动 交友 discuz
查看: 21|回复: 0

【畅言】你真的了解软件开发的本质吗?

[复制链接]

525

主题

525

帖子

1839

积分

管理员

Rank: 9Rank: 9Rank: 9

积分
1839
发表于 2017-11-15 14:16:17 | 显示全部楼层 |阅读模式
这时可以进一步来考虑下面的情形:两个人同时生产杯子,厂方安排一个人用工艺a,另一个人用工艺b,这个时候前者一小时生产5个,后者1小时生产6个。这个时候单纯比较5和6事实上是不公平的,因为这1个杯子的差距可能是工艺造成的。
对人进行量化管理的基石是:量化后的数字主要受个人表现这一个因素的影响,否则将产生巨大的不公正,并对个人工作意愿产生不良影响,是真正的事与愿违。
具体来看:软件本质上是只有人才能处理的东西,因此公司中程序员群体的衰落一定会导致软件自身的衰落,只有优秀的程序员群体,才能保证软件的持久成功,这是必然性。但优秀的程序员却不一定确保当前项目成功,任何人在细节上的小疏忽,都可能导致软件在市场上崩溃,死锁,进而导致灾难性后果,这就是细节决定成败。
《畅言》第七期:【[畅言]企业号会是微信的滑铁卢么?】微信企业号,是微信推出针对企业管理的平台,企业号能在移动互联网上,为企业提供对内部员工的管理、沟通与服务。强大的微信介入这个领域,让很多做企业软件的有一种狼来了的感觉,但这种感觉靠谱吗,微信能成功吗?
这就是上面的题目的来源,在忙于解决具体问题的同时:谁还愿意谈谈软件开发的本质?
                               
                               
                               
总结来看,在软件开发中,数字含义的模糊性会导致使用数字进行评价包含非常多的不公正,这种不公正会对工作意愿构成致命伤害,所以个人层面的量化管理在软件开发面前,几乎必然崩溃。
---《完美软件开发:方法与逻辑》
为了严密一点,我一般这么描述软件的本质:
比如:有个Bug让程序崩溃了,而程序明天就用,最好的方法可能还是赶紧调试,而不是思考什么本质。
这也就意味着在软件这一大的范畴里,两种矛盾的说法同时成立,并不是什么值得惊讶的事情。只要思维承载的东西蕴含着彼此对立的东西,那么两种对立的观点同属于软件这一范畴,并且同时争取,一点也不稀奇。这很可能是大家吵来吵去的一个根本原因,因为我们总是喜欢用自己的经历来定义软件是什么以及判断标准,但如果这种经历来自完全不同的两个领域,并且互相矛盾,那就只能吵架。实际上只有基于软件是一种思维这样特质推导出来的东西才更有普适性。
软件是一种固化的思维,这一点决定了许多的事情。从特质上来看,既然软件是固化的思维,那就必然同时具备思维以及思维所承载之物之特质。
在什么时候对本质的思考会有用
软件的本质是什么
思维的特质是指:思维的澄清通常是渐进的,思维自身是不可度量的,思维的主体一定是人,思维通常由概念和逻辑组成,思维的无边界化(灵活易变)这样的特质。这部分特质是共通部分,同时属于所有软件。思维承载之物之特质是指:当思维的对象是数学的时候,思维本身也就具备了数学的特质;当思维的对象是商业逻辑的时候,思维自身也就具备了商业逻辑的特质。
《畅言》第八期:【[畅言]让软件公司的管理多一点“灵魂”】不少软件公司的成功是源自产品、人口红利,而不是因为管理,甚至有的公司的管理带来的是负值。这样的公司之所以成功,只是因为正面值太大。而另外一面,现实中很多的软件公司,其管理很可能已经陷入了困境。而这是慢性毒药,带来了恶性循环。如何解决?

看过我之前文章的人,可能会感觉到我对不加思考的所谓分享是持鄙视态度的,不管这种分享被冠以干货,经验或者随便什么名字。不是说这类分享没价值,而是说越是这类分享越适合具体问题,而不适合影响因素过多的事物,比如管理,比如文化,比如方法论,比如对软件本质问题的认知。
既有属于所有软件的共同特质,也有特属于某类软件,甚至同其他类软件完全相反的独有特质。
软件开发的输出是代码,而代码自身属于固化后的思维。在度量思维时,多少、大小、长短、厚薄这类惯常的度量方向,并不具有多大意义。就好比说,不能讲一个人代码写的越多贡献就越大一样。
简单来讲越处理全局性长期性问题的时候,对本质的认知越能起点作用;而越是眼下就用类型的工作对本质问题的思考越没什么帮助。
本质问题的思考往往不作用于当下,而只对未来产生潜移默化的影响,当然也可能没等产生影响,当事人就失去了所有机会。它的关键价值在于可以帮助一个人形成属于自己的方法论。软件是个很奇妙的东西,更像每个人都在横看成岭侧成峰状态的东西,所以很容易大家都自我感觉良好,看别人大大的不对,这时候要想不只局限在怎么解决一个Bug,就要思考一点本质的问题。
好比说,不同的工人在同等条件下生产杯子,一个人一小时生产5个,一个人1小时生产6个,那显然后者要好于前者。这时,5和6可以用来比较的前提是两个人的生产条件相同,比如生产工艺等。在这种情况下,量化后的数字为个人表现的函数,因此量化管理基本上是公正的。
大多时候,软件的情况比后一个情形还要糟糕一些。在软件开发中,往往既没有办法清楚的界定一个人的输入,也没办法清楚的界定一个人的输出。
这世上同时存在着两种对立的声音:本质决定成败和细节决定成败。偏好本质的人喜欢说本质论。偏好细节的人则喜欢说精细化管理。但如果在较长的时间轴上考量这两种观点,就会发现他们之间并不真的对立。
本质决定大尺度时间上的走势和必然性,而细节则决定差异(包括短期成败)。比如说:人的本质特征是能思考,有一个头,会衰老,寿命有限等,但区别不同人却不是这些,而是性格,肤色,发色等细节。
软件开发的输入是需求,对需求自身的复杂程度眼下来看还只能依赖判断,而不能精确度量,现实中并没有一种有效方法用以度量需求。
《畅言》第六期:【[畅言]不把C作为第一门语言是个好主意么?】不少人认为,第一门语言最好不要学C,而V众投发起人李智勇却不这么看。他认为如果真想做好开发,想更好地实现人生价值(包括现金价值),那么打基础很必要,而从C语言,这种厚积薄发的语言开始学习学起,则很必要。
诚然思维的表现形式是可以度量的,我们可以通过页数来度量一本书的厚薄,通过分钟来度量一部电影的长短,通过代码行来度量软件,但这种度量所反映的内涵是有限度的,精度也是有限度的。最终结果很可能是人员之间的差距是由误差或其他非主观因素造成的,而不是由个人工作好坏所造成的。
如果有这类思考和认知,想必做某些决定的时候正确性会稍微提高一点吧。
本质决定成败还是细节决定成败
我们当然可以到StackOverflow上分享某个问题的具体解决方法,因为具体技术类问题只依赖于简单的上下文;但我们真的可以用一种简单问答的形式去解决管理、文化、方法论上的问题么,显然是不行的,这需要一种更系统的思考,也就是我之前经常提到的特殊到一般,一般再到特殊的过程。但在具体思考解决问题前,其实还有个事情要做,你要对问题的载体有所认识,对IT人,问题的载体几乎一定是软件,那么也就等价于需要对软件的本质有所认识。
作者介绍:李智勇,V众投发起人,《完美软件开发:方法与逻辑》作者。目前正在免费发布《程序员生存定律》,微博:李智勇SZ,微信:vfacebook。
《畅言》是CSDN新栏目,供大家各抒己见。只要你看完CSDN文章或评论后有话说,都可以通过电子邮件(zhangyong@csdn.net)投稿,从而获得上CSDN首页表达自己观点、想法的机会。《畅言》不怕观点“雷人”,只要你逻辑表达清楚、数据引用可靠,你敢投稿,我们就敢首页!欢迎大家畅所欲言。

                               
但当我们要思考怎么让一个方法论落地更适合自己的时候,对本质的思考就能起点作用。比如始终会有公司会尝试按Bug数和代码行来度量一个人的绩效。如果结合对本质问题的思考,一般来讲就不会做这类决定。
既然思维自身的特质是复合的,那么作为固化思维的软件,其特质必然也是复合的:
成败自身虽然万众瞩目,对个体而言却只是一种偶然和机巧。当事人可以很努力的平衡本质上的追求(长期视点)和细节上的追求(短期视点),但变更的始终是一种成败可能性。
回复

使用道具 举报

Archiver|手机版|小黑屋|赌大小官网  

GMT+8, 2017-12-13 09:43 , Processed in 0.215358 second(s), 20 queries .

Powered by Discuz! X3.3

© 2001-2013 Comsenz Inc.佩佩设计

快速回复 返回顶部 返回列表