软件工厂是否真的可能存在?

一点说明:作为程序员,通常心里是讨厌软件工厂的,但很多时候问题自身皆有其内在理性,并不以个人的偏好而改变其发展的轨迹。

所以程序员一旦谈及和自身喜好相关的问题时,尤其要摒绝个人好恶,否则就会离问题的真相越来越远,而只有一腔情绪。

就我个人观察软件工厂大致处在这样一种地位:经营管理者迫于成本的压力,总是潜在的期望其可能实现;而程序员群体自身则总是对其嗤之以鼻。

为什么在经营层面软件工厂有如此大的诱惑力?

这不难理解,如果软件可以用工厂的模式来运作,那么程序员的可替换性将被无限强化,这样软件开发的成本就可以大幅度降低。

看看近二十年来中国制造的影响,就可以理解这种廉价劳动力所蕴含的巨大杀伤力。

经营层面话题可以无限丰富,但永远也无法摆脱的则是永恒的利益,而这些利益又是不得不争。

外包,外协人员所有这些东西的出现貌似偶然,但终究是利益驱动。

同样的原因,很多人也总是忘不了软件工厂。

但软件工厂的方向实在是错误的,这种错误不在于口水上的是是非非,而在于使用软件工厂模式投入产出比很低,一样会照成利益上的损失,而非相反。

工厂的特征是按照既定的工艺流程,大批量生产同样的东西,这时候通常会有规模效益。

而软件开发是通过明确概念和逻辑来一次性的创造东西,这时候的特征是规模不经济(diseconomy of scale)。

这点是有很多工程数据可以支撑的。

这也就意味着,创造,创新性的东西是无法和工厂的特征相结合的,而更类似于某种工艺的确认过程。

勉强为软件开发导入工厂模式时,很多人会努力切分想(设计)和做(编码)。

这里的问题在于软件开发中想和做是无法切的干净利落的,想约定了做的方向,但做的过程中必然带着对想的深化。

对于全新的开发,不管需求分析还是架构设计都很难摆脱迭代的特征,这个时候需要的是全员参与及积极的沟通。

独裁体制会阻塞这种信息回路,进而降低效率。

我们可以用一个很简单的公式来做些推导:

 生产率:Productivity =  Scale/MM  单位:KSLOC/MM

其中,Scale代表最终软件产品的规模,我们用代码行来做度量规模的单位。

MM则是开发此软件产品所花费的人月。

而与此同时,Scale = Coding Speed *Coding MM。

Coding Speed是指一个程序员编写代码的速度(不是指生产率),而Coding MM则是指所有程序员 用来编码的时间。

把这两个简单的公式合在一起,生产率的公式将变为:

Productivity =  Coding Speed* CodingMM/Total MM  单位:KSLOC/MM

如果我们假设Coding Speed是一个程序员写出Bug最少,质量最佳代码的时间,那么显然生产率主要和程序员的能力以及编码所投入的时间有关。

而软件工厂模式恰恰与此相反,编码速度较低,耗费在沟通上时间会多,所以生产率大致上是低的。

顺道一提:李开复先生的公司叫创新工厂,这很有意思,从本质上看,专注创新的一定不是工厂,而工厂的使命也一定不主要是创新。

这是一个充满矛盾的名字,只是不知道从何而来。

相关推荐