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

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

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

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

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

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

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

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

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

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

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

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

而软件开发是通过明确概念和逻辑来一次性的创造东西，这时候的特征是规模不经济(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最少，质量最佳代码的时间，那么显然生产率主要和程序员的能力以及编码所投入的时间有关。

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

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

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