Question

^「《人月神话》（The Mythical Man-Month）是布鲁克斯（Frederick Brooks）所写的一本软件项目管理名著。所谓“人月”就是一个人在一个月内所能完成的工作量。假如某个项目预估需要12个人月，那么派4个人处理这个项目，理论上需要3个月，派6个人则只需要2个月。但是，布鲁克斯认为这种换算机制在软件业行不通，是一个神话，因为软件项目是交互关系复杂的工作，需要大量的沟通成本，人力的增加会使沟通成本急剧上升，反而无法达到缩短工期的目的。在本质上，软件项目的人力与工期是无法互换的，当项目进度落后时，光靠增加人力到该项目中，并不会加快进度，反而有可能使进度更加延后。（该书英文版已由人民邮电出版社出版。）——译者注」

幸好开发互联网软件需要的程序员比较少。我曾在一家中等规模的桌面软件公司工作，那里的工程部规模就超过100人，但是其中只有13人负责产品开发，剩下的人负责软件发布、软件移植以及其他事情。开发互联网软件，你最多只需要那13个人，因为不存在软件发布、软件移植以及其他事情。

Viaweb的开发者只有3个人^。我一直在不停地招聘，压力很大，因为我们要把公司卖掉。我们很清楚地知道，买家不愿花大价钱买下一个只有3个程序员的公司。（解决方法：雇更多的人，在公司内创设其他项目，让他们去做。）

^「罗伯特·莫里斯写了客户下单的前台订单系统，特雷弗·布莱克韦尔写了图片系统和后台管理系统（商家用来处理订单、査看统计数据、修改设置等），我写了站点生成器（商家用来搭建网站的外观）。订单系统和图片系统的开发语言是C和C++，后台管理系统主要是Perl，站点生成器是Common Lisp。」

开发软件需要的程序员人数减少，不仅意味着省下更多的钱。正如《人月神话》一书中所指出的，向一个项目增加人手，往往会拖慢项目进程。随着参与人数的增加，人与人之间需要的沟通呈现指数式增长^。人数越来越多，开会讨论各个部分如何协同工作所需的时间越来越长，无法预见的互相影响越多越大，产生的bug也越多越多。幸运的是，这个过程的逆向也成立：人数越来越少，软件开发的效率将指数式增长。我不记得我们在Viaweb开过讨论如何编程的会议。步行去吃午饭的路上，我们就能把该说的话说完，从来没有例外。

^「这里的“指数式”（exponentially），我用的是口语中的表达方式。更合适的词应该是“多项式似的”（polynomially）。」

如果要说有什么缺点，就是由于开发人员比较少，每个程序员都必须承担一点儿系统管理的责任。当你在服务器上发布软件时，必须有人监控服务器，但是由于人员太少，监控员只能由开发人员兼任。Viaweb有许多系统组件，变动非常频繁，导致应用软件和系统软件之间的界线很难区分。硬性指定一条界线将限制我们的开发。所以，虽然我们总是安慰自己，公司运营很快就能走上正轨，一两个月后就能平稳发展，那时就可以雇一个专职的系统管理员让他专门负责服务器了，但是这个愿望一直没有实现。

只要你还在很活跃地开发产品，就免不了要亲自做系统管理，我认为没有其他可能。如果你梦想写完代码，向服务器递交（check in），然后就可以回家，一天工作结束，这在互联网软件身上肯定没有实现的可能。互联网软件是活的，每时每刻都在你的服务器上运行。一个严重的bug影响的可能不是一个用户，而是所有用户。如果某个bug破坏了硬盘上的数据，更是必须马上修复，诸如此类。我们的心得是，第一年之后就不必每分钟都盯着服务器了，但是对新变动的部分一定要密切关注。不要在半夜里发布代码，然后回家睡觉。