访谈
PDF与 Joel Spolsky 的对话
构建一家优秀的软件公司需要什么
Joel Spolsky 从来都不是一个会隐藏自己观点的人。自 2000 年以来，他凭借其在广受欢迎的 Weblog “Joel on Software”（http://www.joelonsoftware.com）上发表的关于软件开发和管理的深刻见解和直言不讳的文章，赢得了忠实的追随者。这位多产的散文家还出版了四本书，并在纽约市创办了一家成功的软件公司 Fog Creek，他认为纽约市非常缺乏以产品为导向的软件开发公司。
Spolsky 创办 Fog Creek 并非出于特定的产品想法，而是为了创建一个软件开发人员的乌托邦，在那里“程序员和软件开发人员是明星，其他一切都只是为了让他们高效和快乐”。到目前为止，他已经成功了。该公司保持了 100% 的员工留任率，同时交付了多款盈利的软件产品。其最新版本 Fogbugz 是一个全面的、基于 Web 的项目管理系统，它使用一种名为 EBS（基于证据的调度）的技术来帮助软件开发人员更好地预测他们的发布日期。
在本月的采访中，《Queue》编委会成员、摩根士丹利的 Ben Fried 在 Fog Creek 位于曼哈顿的时尚办公室与 Spolsky 进行了会谈，讨论了 EBS 的工作原理、Web 2.0 的挑战以及为什么军队培养不出优秀的软件管理者等问题。
BEN FRIED 在您创办 Fog Creek 之前，您做了很多事情。是什么让您走到这一步？
JOEL SPOLSKY 我的职业生涯始于微软，我真的很喜欢那里。如果不是因为我不喜欢住在西雅图，我会在那里待很长时间。我在纽约有很多朋友，而且这里的生活更令人兴奋、更充满活力。
我回到纽约，在各个地方辗转反侧，所有这些地方都有些有趣，但我对纽约缺乏真正的技术产品公司感到沮丧。纽约肯定有很多地方可以从事技术工作。其中大多数是银行。下一个最大的类别可能是娱乐业。然后有一段时间是互联网公司。但是对于软件开发人员来说，没有什么比在一家软件公司工作更令人兴奋的了，而且我找不到一家足够接近软件公司、围绕让软件开发人员快乐而组织起来的公司。因此，由于找不到地方工作，我就创办了一家。我想如果谷歌早几年在纽约成立，我可能就去那里了。
BF 您曾雄辩地谈到，您认为自己的使命是为软件开发人员创造一个乌托邦，并且由此产生的东西自然会盈利。这听起来有点像谷歌。
JS 据我所知，谷歌在某些我所宣扬的事情上做得非常好。话虽如此，谷歌也忘记了一些事情。例如，我认为谷歌有点过于多元化，它同时进行的产品创意太多了。“20% 时间”的想法在理论上很好，但它产生的想法太多，一家公司无法跟进。而且它的招聘速度太快了。谷歌的人可能不这样认为，但他们肯定招聘工程师的速度太快了，以至于无法保持单一、统一的企业文化和共同价值观，从而实现高效生产。
BF 您不是以色列国防军（IDF）的一名士官吗？有人可能会说，当伞兵有助于成为软件公司的首席执行官。
JS 我偶尔会回想起军队在军事环境中创造凝聚力和领导力的方式，并考虑它是否适用于民用领域。但我最近发现它根本行不通。军队在领导力方面存在其他机构没有的问题：具体而言，它需要能够命令人们做自杀式的事情，并让这些命令立即得到遵守。考虑到这一点，它有一种非常特殊的纪律形式和非常特殊的训练形式。如果你试图在一家软件公司这样做，每个人都会离开并去另一家公司。
BF 我认为很多人都对理解大公司和小公司之间的区别，特别是软件产品公司和其他类型的公司之间的区别感兴趣。您做过大公司，也做过小公司，并且您创建了自己的公司，那么您如何区分它们呢？
JS 我真的觉得，对于一个热爱软件并且是一位优秀的开发人员来说，在一家软件公司工作有很多好处，主要是因为您了解和擅长的事情与企业擅长的事情以及您获得晋升的类型直接相关。但是，实际上，银行业有点有趣，因为归根结底，您所做的 95% 实际上是以某种方式进行的信息技术。即使是衍生品在某种程度上也是一种代码形式，尽管它也具有交易方面。因此，在银行业中，一位最初是开发人员的人可能会晋升到实际经营银行的地步——这种情况已经发生过了。因此，您不会感到完全错位。
另一方面，如果您作为软件开发人员去一家娱乐公司，例如我在维亚康姆公司为 MTV 工作时，或者任何其他类型的公司（例如保险公司），您实际上都是分包商/服务提供商。您每天思考的事情与首席执行官从小处着手思考的事情不同；它们实际上是非常不同类型的事情。
BF 您没有做为公司赚钱的事情。
JS 对。您通常在成本中心，而不是利润中心。同样，银行业略有不同，因为对于银行而言，如果您可以比其他所有人更快地计算出某些东西，您就会成为利润中心的一部分。但我发现，作为一名软件开发人员，您不可避免地会在一家软件公司更快乐。
BF 大公司和小公司又如何呢？当您在微软工作时，那里有大约 8,000 人。
JS 我认为当我第一次以实习生的身份加入微软时，那里有 5,000 人，当我成为全职员工时，人数增加到大约 10,000 人。现在，肯定有 35 亿人或者更多。这个地方有一种非常不同的味道，这对我来说真的很奇怪。当时，我欣赏大公司的好处。感觉有很多有趣的事情可以做。您可以随时跳槽到新工作并留在同一家公司。如果您对正在做的事情感到厌烦，您可以转到很多其他工作岗位。
另一方面，成为一个庞大项目中的一个小齿轮，无法真正向任何人描述您所做的事情，无法真正影响或影响事情的发生方式，这有点奇怪。您在微软所做的几乎 95% 的事情都以某种方式是在喂养野兽。您在为微软工作，而不是为您的产品工作。您并没有直接使您的产品变得更好。您正在努力创建会议，这些会议将导致某些事情发生，从而在某个时候使某个产品的某个部分变得更好。
BF 我读到一篇博客，内容是关于设计关闭菜单的某个元素需要多少人和多长时间。
JS 通常有很多人不断开会，争论一些很小的事情，然后他们会把它弄错，因为它是由一个委员会设计的。
基本上，一家小公司有一种味道，而一家大公司有点像入住拉斯维加斯的百乐宫酒店。它是一家不错的酒店，但有 5,000 个房间，所以不要指望有人记住您的名字。一家小公司更像一家住宿加早餐旅馆。您会玩得很开心的，因为您与人相处融洽，而且这是一种更友好的体验。您并不介意浴室在走廊的尽头，因为这些人为您做了特别的素食餐，然后带您游览了城镇。另一方面，您可能会在一家住宿加早餐旅馆里，那里有奇怪的皮革工具和很多猫。
BF 请告诉我们您公司成长的经历。随着 Fog Creek 的发展，您所做的事情发生了怎样的变化？
JS 基本上，我在任何给定时间所做的事情都是 Fog Creek 随着规模扩大而突然必须做的任何新事情，而且没有人来做。小公司和大公司之间的区别在于，在小公司，您仍然必须做所有相同的事情，但您必须做得更少。因此，您需要有人来做，比如，市场营销，但实际上只占一个人工作量的 0.03%。您需要有人倒垃圾。您需要有人做簿记，但您实际上还没有全职簿记的需求；即使到今天，在 Fog Creek，簿记大约是一个人每周一天的工作量。因此，在那个时候您真的无法聘请簿记员。有一段时间，我们没有办公室经理，也没有人接听电话。
随着规模的扩大，这些任务开始达到您可以聘请全职人员来完成它们的程度，而首席执行官则停止做这些事情。现在，在任何一天，我们实际上至少有两名全职人员来回复客户电子邮件、接听电话、与客户交谈、跟进客户以及做这类事情。
在很长一段时间里，我的活动之一是公共关系——营销、广告和提高 Fog Creek 的知名度。我通过撰写“Joel on Software”来做到这一点。现在，这并不是“Joel on Software”的真正目标，事实上，“Joel on Software”早于 Fog Creek。经典的“Joel on Software”文章都来自 2000 年夏天，在我创办 Fog Creek 之前。
当我有时间的时候，我会保持这种状态。希望，如果我幸运的话，我将能够再招聘一些关键人员，并完成所有日常工作，以便我所做的大部分工作都是构建事物。
BF 谈到招聘，您在招聘方面谈到的一些事情引起了很多人的共鸣：“聪明且能把事情做好的人”已成为许多招聘开发人员的人的座右铭。当为 Fog Creek 招聘时，您会寻找哪些具体的品质或才能？
JS 我寻找很多东西。例如，我不在乎您是否从未使用过指针，或者您是否从未使用过递归，或者您是否从不需要了解指针或递归。我只是发现，擅长这些事情恰好与擅长各种更重要的问题相关。
我对为什么会这样的理论是，为了做好这些事情并理解它们，您需要同时在不同的抽象层次上思考问题。这是大多数人没有的一种才能，而且缺乏这种才能，他们就不会成为优秀的程序员。
学习它是一件好事，锻炼您大脑的一个好部分。即使人们没有这种才能，但如果他们愿意为此努力工作，那么很可能这些东西是可以教给人们的。
BF 但它本身并不是一个关键的事情，对吗？
JS 作为一名程序员，我感觉我们不必再考虑指针真是太好了，而且我们必须编写的算法实际上也很少再使用递归了。但这让我很难招聘，因为我没有过去存在的那种能力，如果人们无法通过学习如何在 Scheme 中编程并在 Pascal 中使用指针进行数据结构的学习，那么这种能力就会将他们从计算机科学中剔除出去。现在，当我在面试中要求某人展示递归知识时，他们可能会无法做到，不是因为他们很笨，也不是因为他们不会递归，而是因为他们从未被教过递归。
BF 开发人员需要管理者有效地管理他们哪些方面？
JS 这是一个很好的问题。我总是把它更多地看作是一种支持角色——就像搬开家具以便他们完成工作——而不是真正的领导角色。开发人员可能需要的一些支持是，例如：“我们需要解决此错误消息的文本。” 这不是计算机程序员一定擅长的事情，因此只需给他们错误消息，让他们继续处理下一件事。
在管理者可以实际为程序员做出决定的范围内，他们所做的都是非常低级、平凡的决定，这些决定可以让程序员继续执行下一个任务。在关于算法、关于大局、结构、代码的决策方面，管理层做出这些决策可能是一个非常糟糕的主意。我认为开发人员的管理者有两个角色：第一，为开发人员准备一个有用且种类繁多的待办事项队列，以便他们可以从队列顶部挑选事项并接下来完成它们；第二，基本上在那里回答开发人员的问题。
BF 在过去的几年里，您写了几本书，而且我看到您的办公室里堆了很多书。您现在在读什么？有什么推荐的吗？
JS 目前关于软件开发和软件管理方面的最新技术的书籍不多，而这些正是我喜欢写和读的书籍类型。不幸的是，我们还没有超越轶事阶段，而超越轶事阶段的尝试通常只是带有统计数据的轶事。
部分问题在于这里真的没有科学在进行，这非常令人沮丧。这同样适用于很多商业写作。写一本名为《星巴克原则》或《戴尔之道》的书非常容易，只需提出一大堆随机轶事，并以某种方式将它们在主题上联系起来，并假装这是一件您可以做到的并获得成功的事情。
而且，瞧，另一个笨蛋然后会尝试在自己的公司里尝试同样的事情。它不起作用，因为它不适用，或者因为它在原来的公司里也不起作用——它只是某人凭空捏造的轶事。这是这个特定领域一直遭受的问题之一。
我们所拥有的是老年人的轶事，像我这样的人，甚至是非常年长的人，像 Gerald Weinberg 这样的人，写出精彩的东西。Timothy Lister、Tom DeMarco、Ed Yourdon——这些人都在写着：“我在这里待了很长时间了。我知道我是一个老顽固，但让我告诉你们年轻人这是怎么回事，哒哒哒哒哒哒哒。这里有一些例子。这表明的是哒哒哒。” 如果您阅读了一堆这样的轶事，您实际上可能会学到一些东西。这有点像我们领域的口头知识。
另一方面，我们真的没有足够的统计数据。例如，我强烈主张拥有带门的私人办公室，我可以给您两个理由。第一，更容易招聘人员。在所有条件相同的情况下，优秀的开发人员会更喜欢私人办公室。第二，更少的干扰意味着程序员实际上能够完成工作。
BF 但实际上有很多数学可以支持这一点——统计学，或者我们称之为伪科学。
JS 伪科学，没错。但是，如果您尝试找到一篇有人实际使用带门的封闭团队和不带门的开放团队的文章，那么只有一个例子：Lister 和 DeMarco 在他们撰写《人件》之前做的一个周末编码实验，他们实际上都尝试过这两种方法。
BF 我认为，如果您关注知识工作领域，那么在干扰管理和注意力管理方面已经做了很多工作，以便在没有干扰的情况下实现流畅工作等等。
JS 我不太确定它有多科学，因为有各种各样的影响需要考虑。有霍索恩效应，这使得永远不可能正确衡量这些事情中的任何一件。软件开发中的不同人之间也存在巨大的差异。有时，一个人可能在三周内完成某件事，而另一个人可能需要一年才能完成。但另一个人可能在三周内完成另一件事，而第一个人可能需要一年才能完成。
不仅生产力存在巨大差异，而且个人技能组合和个人对某些事物的才能也存在巨大差异。而且我们正在做的工作非常奇怪，在实验中不容易控制。进行对照实验几乎是不可能的。
没有太多数据。似乎唯一的证据是，很容易找到 10 倍的生产力差异，而且没有人知道为什么，而且更快或更慢并不一定意味着您做得更好或更差。
BF 您一直在谈论 Fogbugz 中的一种叫做基于证据的调度。这有关联吗？
JS 不完全是。它实际上更像你们在银行业所做的风险管理。在基于证据的调度中，您提出一个计划，然后一群人创建估算值。然后，您不是将他们的估算值加起来——而不是相信他们——而是做一个小的蒙特卡洛模拟，您可以在其中查看开发人员过去的速度，相对于他们的估算值而言。您使用与过去相同的概率分布（我们称之为概率），并模拟您所有的未来。您获得的不是日期，而是一个概率分布曲线，该曲线显示了产品将在某个日期发布的概率。
我发现的有趣之处在于，人们常常低估。但您可能会认为他们也高估了，因此如果您有 10 件事情要做，只需将所有这些估算值加起来，其中一些会晚到，而另一些会早到，您仍然应该得到相同的日期。您将通过提前做其他事情来弥补迟到的事情。
但是当您想到软件任务时，当事情出错时，它们花费的时间是预期时间的三到四倍。如果我告诉您我有一个 8 小时的功能，那大约是 8 个小时的工作量。现在，它会花费 8 个小时吗？会。会花费 6 个小时吗？当然。会花费两天吗？肯定会。会花费一周吗？是的，可能有 10% 的概率，因为您发现了一些巨大的问题，而且这是一件您必须编写代码的新事物，而您完全忘记了它，它将花费您一周的时间。
现在，它会花费零小时吗？不，那是不可能的。会花费负 32 小时吗？它永远不可能花费负 32 小时。您可能会超过 32 小时；您只是不可能少 32 小时，因为那会让您回到过去。
BF 这几乎都是坏处，没有好处，对吗？
JS 在某种程度上，8 小时是平均值，它有一个很长的右尾。
BF 在某种意义上，它是无限的，或者几乎是无限的概率，对吗？
JS 是的，有些 8 小时的功能可能会在某些概率下花费 6 年的时间。但它确实有一个非常长的右尾，这意味着实际上，如果您将两个功能加起来，一个功能是 8 小时，概率为 50%，另一个功能是 8 小时，概率为 50%，您可以在 16 小时内完成它，但概率不是 50%。可能只有 30% 的概率。这里最重要的观察结果是，即使您非常擅长估算 50% 的点，将两个估算值相加来获得这些组合功能的估算值在数学上也是不正确的。您必须做一些类似基于证据的调度的事情，您可以在其中使用历史数据——而这实际上是风险分析。
BF 既然您对人与计算机的交互方式充满热情，我想听听您对当前关于 Web 2.0 用户界面技术的讨论有何看法。这些东西让我们的生活变得更好还是更糟？
JS 它让程序员的生活变得更加艰难，但当程序员做得好时，它可能使用户受益。当用户界面以期望的方式工作，并且用户模型与程序模型相对应时，这对用户来说是很好的。
另一方面，对于程序员来说，这要困难得多，原因有几个。首先，您编程的语言数量增加了。您总是为浏览器编写一些 JavaScript。然后，您使用任何服务器端应用程序语言编写代码——Java、PHP 等。然后，您使用 HTML 和 CSS 编写代码。您需要学习、了解和跟踪很多语言。
代码存在于许多不同的地方。仅仅因为您编写了一个小函数来计算一个地方的当前时区的时间——假设是服务器端 PHP——这是否意味着它将在 JavaScript 中为您工作？这需要各种协调。可能出错的事情数量荒谬。您至少必须在三到四个不同的流行浏览器上进行测试。
我们再次回到了这样一个世界，您必须编写非常少量的代码，并使它们非常紧凑和非常快速。有一段时间，我们可以奢侈地编写非常草率的代码，并且永远不必费心优化任何东西，因为计算机“足够快”，代码量实际上并不重要。但是，当您编写客户端 JavaScript 时，会存在下载时间，然后代码必须编译。您可以编写在客户端的代码量实际上是有限制的。
BF 您曾写过 Windows 桌面开发几乎已经死了。您仍然认为 Web 对于人们想要做的大部分事情来说都足够好吗？
JS Web 足够好并且正在变得更好。只是现在很少看到人们再编写 GUI 应用程序了。
BF 那么 Adobe 现在通过 Flash 以及现在的 Adobe 的 Apollo 和微软的 Silverlight 所处的这个世界呢？这些都是以某种比 HTML 稍好的方式在 Web 浏览器中的矩形中编写某些内容的方法，对吗？
JS 或者在您的 Web 浏览器之外。
BF 是的，Silverlight 允许它在您的 Web 浏览器中，而 Apollo 似乎将 Flash 中会在您的 Web 浏览器中的东西放在您的桌面上。他们应该让我们使用我们以前拥有的工具，还是这实际上是更好的技术？
JS 某些方面更好，例如我们在 Fogbugz 中使用的基于 Flash 的图表，您无法在 HTML 中正确地完成这些图表。因此，在某些受限领域，这些技术有很多好处。另一方面，我认为人们不太可能将这些技术用作编写基于 Web 或非基于 Web 的应用程序的起点，因为在某种意义上，他们将自己锁定在某个特定供应商的后备箱中。但话又说回来，可能有一些有用的东西。我认为 Silverlight 最先出现的有用功能可能是编译后的 JavaScript 功能，因为实际上在某些较大的 Web 2.0 站点上，客户端 JavaScript 的编译会在页面唤醒之前增加大约一秒钟——我们谈论的是在典型的 Ajax 站点上编译大约 1 兆的代码。
BF 为了总结一下，我想谈谈您最出名的事情：“Joel on Software”。尽管您不同意“博主”这个词，但您被广泛认为是思想领袖博主，他在很大程度上定义了技术世界中博客的含义。它是否帮助您更好地思考？它是否帮助您更好地运营 Fog Creek？
JS 总的来说，我不认为写博客或个人文章一定是任何首席执行官应该做的事情。一方面，我做过这件事，并且它在某种意义上使 Fog Creek 受益，因为我们已经获得了我们产品的广泛关注。另一方面，很多人都说：“这是一个好主意。我也要这样做。” 我不想说我一定启发了他们，但他们似乎试图做和我写关于他们自己的软件所做的事情相同的事情，但他们只是没有获得同样的受众。我不知道为什么会这样，但他们没有，而且这对他们来说效果不是很好。很多时候他们只是放弃了。
对于您的朋友和家人来说，拥有一百万个博客并没有什么错，偶尔有一百万个博客中的一个说出一些有趣的事情并获得 15 分钟的成名时间也没有什么错。但我们不会有一百万个软件博客在那里，并且实际上每月有 100 万人阅读。并不是说现在没有比我更好的博主在默默无闻中消沉。
最初发表于 Queue 第 5 卷，第 5 期—
在 数字图书馆 中评论本文
更多相关文章
João Varajão, António Trigo - 评估 IT 项目的成功：感知与现实
本研究通过提供对 IT 项目成功的新见解，对实践、研究和教育具有重大意义。它通过报告项目成功（而不仅仅是项目管理成功），扩展了关于项目管理的知识体系，该项目成功基于几个客观标准，例如项目后阶段客户对可交付成果的使用、客户对项目相关支持/维护服务的聘用、客户对新项目的承包以及客户向潜在客户推荐供应商。研究人员可以找到一组标准，他们可以在研究和报告 IT 项目的成功时使用这些标准，从而扩展当前对评估的视角，并有助于得出更准确的结论。
Abi Noda, Margaret-Anne Storey, Nicole Forsgren, Michaela Greiler - DevEx：实际驱动生产力的因素
开发者体验侧重于开发者的生活体验以及他们在日常工作中遇到的摩擦点。除了提高生产力外，DevEx 还通过提高效率、产品质量和员工保留率来推动业务绩效。本文提供了一个理解 DevEx 的实用框架，并提出了一个测量框架，该框架将来自开发人员的反馈与关于他们与之交互的工程系统的数据相结合。这两个框架为领导者提供了清晰、可操作的见解，让他们了解要衡量什么以及在哪里关注，以便提高开发人员的生产力。
Jenna Butler, Catherine Yeh - 感同身受
新冠疫情在许多方面改变了人们的工作方式，但许多结果本质上是自相矛盾的。对一个人有效的方法可能对下一个人无效（甚至对同一个人在第二天也可能无效），我们尚未弄清楚如何准确预测什么对每个人都有效。正如您在本文描述的综合角色中看到的那样，有些人与孤立和孤独作斗争，很难与他们的团队进行社交联系，或者发现与远程团队进行混合工作的时间压力不堪重负。其他人则对这种新发现的工作方式感到高兴，享受更多与家人相处的时间、白天锻炼的更大灵活性、更好的工作/生活平衡以及为世界做出更大贡献的愿望。
Bridget Kromhout - 容器不会修复您破碎的文化（以及其他残酷的真相）
我们经常关注技术反模式，却忽略了我们社会结构内部的类似问题。剧透警告：许多看似技术性的难题的解决方案可以通过检查我们与他人的互动来找到。让我们来谈谈您在与那些被称为人类的讨厌生物一起工作时想要了解的五件事。
© 保留所有权利。