编写软件需要多少人？

讲个笑话，问：拧个灯泡需要几个程序员？答，需要：一个业务分析师，一个产品经理，一个流程或者项目经理，一个架构师，一个DBA，一个设计师，一个QA经理，一个发布经理，一个测试人员……嗯，我忘了谁了吗？

真是个糟糕的笑话。

现在，大多数组织都有很多人参与软件创作。现代软件开发通常有大量专职化的角色，包括程序员。

在1981年我开始工作的时候，大部分的角色不是独立的人，很多情况只有两个：经理和程序员。我工作的国防承包商基本上拥有：经理和程序员，需要程序员的经理。当我被经理指派为程序员时，要做任何工作：编程，测试，交付，记录文档——无论什么都做。当时有个程序员-分析员的概念，用来区分谁做第一部分，但我记得我是什么都做了。

当然，其它公司怎么做的是个谜——没有互联网和现代的沟通渠道，别人怎么做的，我们无从知道。

什么都做有个好处，我对好多事情，包括和客户沟通，设计界面，识别和跟踪计划，架构，还有其它各种非编程工作，都感到舒适。今天，除非是在一个启动环境（有时候甚至没有），作为程序员，除了编码很少做任何事了。人们甚至取笑程序员做像设计这样的工作。

在80年代，程序员要做的好多事，今天都是专职的做了。当然那时的应用只有很少的交互部分，如网络和数据库。但我们的工作环境缺乏：外部帮助、开源工具、以及任何现代沟通工具，如电子邮件等。

另一个区别是大型团队基本上无法组织。想象一下100个程序员一起做一个应用，没有电子邮件或Slack，代码库，JIRA之类的工具，而且只能通过联邦快递和磁带驱动器来协调软件。团队之间合并代码是个手动过程——除非你真的非常小心谨慎，否则很容易出错。

我的团队就非常典型：我们在得克萨斯，作者在纽约，在8个月里每隔一天通过联邦快递交换代码。后来在1993年左右Deltagraph的最后一个版本中，因为加利福尼亚州的出版商增加了两个程序员，我们又做了一次交换代码。

今天没有人会这样创建软件。今天我们有网络，工具和流程来协调庞大的团队，但是成本非常高，创建了许多不同的专业角色来支持这个团队。有趣又让人惊讶的是，有了这么多工具，却需要更多的人来做事。

这些年我一直在小型编程团队，除了Deltagraph在1993年最后一个版本中有6个程序员，墨西哥的一个项目在2000年年中有40个（一个巨大的失败），4个是我做过的项目（包括大项目）里最多的。

当然，在过去的几十年中，项目的非编程方面已经获得了越来越多的角色。有趣的是我们如何用4个程序员，2个测试员和一个产品经理，创建了Deltagraph，并且创建了一个领先全球的产品。今天，我在一家庞大的非技术公司工作，有80个iOS程序员和更多的非程序员，支持人员和管理人员。然而，整个应用程序（基本上有两个类似的）功能并不是那么复杂。

我工作的团队现在只有两个iOS程序员（共有三个人），我们为两个程序员创建了一个大的应用程序，将它移植到第三个业务单元的应用程序，并在同一时间内构建了三个内部应用程序。

另一方面，墨西哥的项目有来自三个国家的40名程序员，每星期飞往同一个房间辛苦工作。三个月后，整个项目陷入了僵局——客户的钱用完了。

在旅行公司（我的两个工作之前）我们也有一个小团队，用20人，设法创建和支持7个产品，其中一半是程序员（4个iOS）。

我仍然喜欢做更多事，不仅限于取工单，做工单，优化代码，更改工单状态，这些现代程序员的角色。

今天的程序员没有和我一样的“经历”，只有你亲自去做，才能体验到它，这就是在初创公司工作的真正有价值之处。从我所知道的情况来看，也不总如此，初创公司往往认为整套的支持人员是必要的，程序员除了编码之外别无他用。这很可能产生高昂的风投资金。

即便有了现代工具和流程，庞大的程序员团队现在是非常普遍的。最近一次会议上，我问过他们的移动团队有多大，有几十个程序员是常态。Uber有100多个，不敢想象Facebook有多少。

他们都做些什么？我认为现在的程序员与80年代相比，每天写的交付代码很少。我认为正规的是写很少的代码，写很多的单元测试，花大量的时间在流程和会议上。如果做这些事，相比之下，我们那个时候可以完成更多交付代码。那时候我们只有很少的工具，没有电子邮件，没有知识库，没有流程，除了我们想到的，坐在一起通过交谈沟通。我们有更多的时间思考构建什么，如何构建，如何测试它；至少我的两家公司（1985-1994）每6个月左右交付一次。因为用软盘装盒发布，要对发行版负责，所以不能经常发布。

请注意，我们不是瀑布方式，创建的所有东西，都是以很久之后被称作敏捷的方式完成的。

今天人们通过自动化管道推出软件，并且每一两周发布一次。在我的工作中，尽管所有人都经历过一个及其讨厌的过程，幸运的是我们每两个月发布一次。如果有大量的人员，各自负责一个大型自动化测试管道组织的很少一部分，就能够很快地把它发布出去，但是要花费很多钱，而且不保证结果一定是好的。

我通常在资源有限的团队工作，即使是大型项目中，我们也有更多的自由来完成任务，但不会定期每周交付产品。大型自动化团队的代价是否值得？也许对有些公司是值得的。

对我来说，宁愿一个非常小的团队，只需要更少的支持人员，做更多的事情。我无法在100个程序员的高压力团队中工作，听起来就无趣。我不知道怎么比较这两者：4个人花费的时间，由100人每周抽出来的产品。

我宁愿做更多的事情、花时间来创建一个优质的产品，而不是花大量的钱，短时间内发布产品。最后，对于您和您的公司来说，重要的是能承受什么代价，有多大的意愿花钱组织很多人，或者消耗多一点时间少花些钱。

是组织更多的人，每个人做的更少，并且需要很多支持人员；还是很少的人各自做得更多？两种方法各有主张。我只是想成为后者的一部分。

http://thecodist.com/article/how_many_people_does_it_take_to_write_software

译者介绍：

陈晏娥，鞍钢矿业运维，专注云和虚拟化实施和技术，云技术社区译者