重生还是死亡？这些公司都重写了软件，结局却不同

本文是对一个古老问题的重新思考：我们是否应该重写应用？重写对软件公司来说，是不是战略性错误？事实证明，处理成熟的代码不仅仅只有这两种选择。

“好像源代码生锈了。”——Joel Spolsky

差不多在 20 年前，Joel Spolsky在他具有里程碑意义的文章《你永远不该做的事情》中痛斥 Netscape 重写了他们的代码库。

他的结论是功能型应用永远不应该从头开始重写。他的论点包含这两方面：

• 应用代码中很绕的部分，通常蕴含通过边角用例和奇怪 bug 而得来的知识。

• 重写是个漫长的过程，期间会阻碍产品的发展，并且此时，竞争对手也可能迎头赶上。

对于很多人来说，Joel 的结论成了一种信仰，对我也产生了很大的影响。。

但是，在之后的几年中，我了解到了一些反对意见，认为在某种情况下，从头开始重写很有必要。例如：

• 有时遗留的代码库实在太混乱了，无法修复，例如即使是非常简单的变更，都需要级联修改代码的其他部分。

• 最初的技术选型可能会阻碍进行必要的改进。

• 最初的技术选型已经过时，使得很难（或者成本很高）招到优秀开发人员。

当然，所有的决策都要和当时所处的环境相结合，有的时候逐步重构会更有意义，而有的时候抛弃原有代码从头开始更有效。

但是，这两个不是所有答案。让我们来快速浏览下这六个故事，看看从中能学到什么。

（彩蛋：每个故事都有基于 ASCII 艺术的摘要。）

1 Netscape

关键字：重写、死路一条

Joel 将 Netscape 的灾难性 5.0 / 6.0 重写作为《永不重写》的引子。

Netscape 浏览器最早在 1994 年发布，它定义了早期商业互联网。在其发布的不到 2 年，Netscape 以 30 亿美元 IPO，开创了互联网新纪元。

Netscape 第一个重量级竞争对手是微软 1996 年发布的 Internet Explorer。

在 1998 年初，Netscape 仍然是浏览器市场的引领者，但非常勉强。Netscape 的零售价是 $49，但是微软免费提供其 IE 浏览器，并以默认浏览器的方式跟随 Windows 操作系统一起分发。

在 Netscape 4.0 发布之后，公司宣布 5.0 版本将免费提供，并创立和资助了名为 Mozilla 的开源社区，由社区进行开发。

这在当时几乎是史无前例的，因为它们的勇敢举动，Netscape 赢得了许多好评。但是，当时社区并没有实际建立。浏览器早期开发者之一的 Jamie Zawinski 对此解释到：

事实是，Mozilla 项目的贡献者包括了来自 Netscape 的大约 100 名全职开发人员，以及来自外部的约 30 个兼职人员，这个项目仍然完全属于 Netscape。

项目组总结了外部开发者不愿意为他们的开源项目做出贡献的其中一个原因是现有代码太混乱：

代码太复杂和混乱了，修改非常困难，因此开发者不想贡献代码。因此我们切换到了新的布局引擎，理论上一个干净、全新设计的代码库会让开发者易于理解和贡献代码。

从干净的代码开始

因此在 1 年后，团队决定废弃 5.0 版本，从头开始开发 6.0 版本。

又过了 2 年，Netscape 6.0 最终发布了。但是甚至在此之后，6.0 版本仍然算不上是一个正式发布版。根据纽约时报评论员David Pogue描述，Netscape 6.0 需要 1 分钟才能启动，并且非常占用内存。同时，它还缺少之前几代浏览器都有的许多可用性相关特性：

打印预览功能没有了，同时将网址从地址栏图标直接拖拽到书签菜单功能也没了。用户无法通过地址栏上通过右键来复制粘贴网址。另外，浏览器不会记录上次运行时的窗口状态，因此每次打开浏览器的时候都需要重新调整窗口大小。最惊人的缺陷是，用户无法通过单击地址栏全选网址。

抛开这些缺陷不谈，更严重的是，在这三年里，Netscape 停滞不前，而 Internet Explorer 抢占了它之前的所有市场份额：

当重写开始的时候，Netscape 份额被微软的 Internet Explorer 大量蚕食。三年后，新的浏览器最终发布时，充满了 bug 并且运行卡顿，而这时 Netscape 的市场份额已经逐渐减少到几乎没有。（图表来源维基百科。）

1999 年，当重写正在进行时，AOL 以 100 亿美元的价格收购了 Netscape。

在 Netscape 6.0 发布的 2 年后，AOL 中的 Netscape 团队被解散。

Netscape 创立的开源社区 Mozilla，之后又进行了一次彻底的重写，2002 年发布了 Firefox 浏览器，而 Firefox 很争气，从微软手中夺回了部分市场份额。

但是，Netscape 作为一个企业已经完了。（很讽刺的是，微软于 2012 年和 AOL签订协议后，获得了 Netscape 遗留的知识产权。）

赢得了这场战役的胜利之后，微软撤回了在浏览器技术上的投入。Internet Explorer 6.0 于 2001 年发布，之后的 5 年中都没有发布新版本。在一些人看来这是一种刻意的策略，目的是为了阻止 web 作为应用程序的平台技术。

经验教训

许多人在争论，从长远角度看，重写并不是一场灾难，因为这个项目最终产出了 Gecko 引擎和 Firefox 浏览器。

但是，当我们在等待新的浏览器来引领 web 技术之前，我们不得不忍耐 IE6 带来的多年停滞不前和令人窒息的垄断。而且，最终终结 IE6 时代的并不是 Firefox，而是 Google Chrome。

另外，关键问题并不是重写对于 web 是否有利，而是从公司的角度来看，这个决定是否是一个正确的选择。虽然 Netscape 丢失市场份额并不完全因为重写，因为法院曾认定微软故意滥用其垄断地位。但是不可否认的是，重写的确是一个助推因素，最终导致一家市值数十亿美元的公司倒闭，数千人被裁员。所以，我同意 Joel 的观点，这次重写带来的后果是灾难性的。

2 Basecamp

2000 年早期，一个名为 37signals 的芝加哥网页设计公司创立，由于创始人Jason Fried和DHH的富有影响力和叛逆的博客，吸引了许多追随者。

当时，我刚刚作为一个网页设计师入行，他们做的37better项目，为包括 Google 和 PayPal 在内的网站做了一系列的重新设计，成功吸引了我的注意。

37signal 为联邦快递重新设计的发货表单（上图），与 20 年后的实际页面 相比，该页面更好

2004 年，他们发布了最初为内部开发使用的项目管理工具Basecamp，并以软件即服务的方式提供。当时，通过订阅使用软件还是一种新奇的方式，大部分项目管理工具还是以带着四位数价格标签的热缩包装盒以及一堆手册的方式售卖，主要功能包括建模核心路径和生成复杂的甘特图。

Basecamp 定价为每个月 $50，为这个领域带来了一股清流，它有非常简单的用户界面，专注于沟通功能。

时间快进到几年前，Basecamp 拥有 50 万忠实用户，每月都有收入。此时 Jason 和 David 开始变得不安起来。

我在几年前的软件商业会议（ Business of Software conference）上听 David 讲了这个故事。他说，他被 Joel Spolsky 提出的重写软件会让公司衰败的观点说服，但同时又被敏捷运动的观点有所启发：

（我）完全接受了超验软件的概念。……代码具有无限可塑性。遗留代码具有无限价值。开发者可以修改任何地方，代码的任意地方都能够被重写。……如果软件难以修改，那就是开发者的失误，开发者技能不行，需要更大的提升。

然而，在经历了他所谓的“七个胖年（seven fat years）”之后，他们陷入了困境——这与技术债无关。

金手铐

他们开始注意到内心缺少激情，不仅没有动力来维护旗舰产品，就连使用自己产品的时间也不多。他们对如何让产品从根本上变得更好有许多想法，但是由于有成千上万的用户基于 Basecamp 来构建工作流，他们每次的改动都会对许多用户产生破坏性影响。

改变的障碍并非是混乱的代码库，而是他们的用户。

当时，他们专注于保持现有用户的基本使用，阻碍了产品的发展，同时也阻碍了新客户的吸引。虽然这不是业务上急迫的问题，但却是一个长远的威胁。DHH 用试图灌满一个漏的桶来打比方：

你可能正在试图堵住每个洞，你可能正在修复所有的 bug，你可能正在修复现有用户抱怨的问题，你以为这样就能避免水漏出去——但是总是有水在往外漏。客户继续他们自己的工作，即使他们喜欢你的软件也可能会弃用。你可以自欺欺人，“嘿，还有大半桶水呢，这只是一个很小的洞，漏点水很正常。”但是如果一直都这样想，桶里的水最终会漏完。

部分原因是因为我们都在从现有客户收集反馈，而没有向未来的客户收集反馈：

到 2011 年，有用户打开了 Basecamp 主页，但是因为我们的想法已经不够好了而放弃购买，我们能够收到多少来自这些人的反馈？没有。我们收到来自反馈基本上都来自于现有客户，他们非常乐意我们仅仅是堵住桶上的小漏洞。

他们开始将盈利产品视为一副金手铐：

我们的首要任务是确保现有用户仍然乐于使用。这样每个月仍然会有进账，新的支票、新的支票、新的支票。很好。但是，我们必须向前伸出双手，“好的，我们绝不会再对软件进行修改。”

剧透警告：他们重写了 Basecamp，而且同样优秀。重写花了 1 年时间，在 Basecamp 2 发布后，注册人数翻了一番。

我认为他们做了 2 件比较有意思的事情，达到了这个效果。

首先，他们没有试图在现有产品上重构，因为他们对如何解决他们最初要解决的问题，有了新的想法。

我们真的可以自大的认为 2003 的想法到 2011 年仍然是最完美想法吗？我的意思是，虽然我之前一直被认为很自大，但是在大概 2008 年之后，就已经改变了。

因此，他们以全新产品的形式发布了 Basecamp 2，同时也没有保证对 Basecamp 老版本的兼容。新版有许多新增功能，同时也去掉和修改了很多原有功能。

这个决定给了他们一定程度的自由。自由是一种激励，激励人们做的更多。不再支持原有产品的某些特性，也帮助他们节省了时间。例如，原版本 Basecamp 允许用户在自己的 FTP 服务器上保存文档，删除了这个特性和其他类似的一些特性，只需要一次商业需求讨论，之后就再也不用了，除此之外还能让新产品按时的推向市场。

“日落”软件是有害的

如何对成百上千的已有用户作出交代呢？用户会因为自己的奶酪被动了之后而大声抱怨吗？

这就是对我来说第二个感兴趣的点，他们没有放弃现有的产品。

David 对“日落”软件的概念嗤之以鼻：

有些人在一些场合提出了“日落”这个委婉说法。……让我们把停止维护软件称为“日落”。……所有用户坐在沙滩上，看着他们所有的数据慢慢消失。这应该会很漂亮！

只有将它称之为“日落”的人才会相信“日落”。没有一个用户真正经历过“日落”之后，还会说“哦，真是太美了。”他们回来一定会说，“呀！我在上面投入了这么多年的工作！现在你们要让我去看‘日落’？”

他指出，当我们强迫用户打包走人，这将是我们做出的“有史以来最严重的战略错误”：因为这样的举动会让所有活跃用户群考虑是否继续使用我们的软件，亦或是寻找其他替代品。

Basecamp 还是我想要的东西吗？如果我们只是想把其中的垃圾移走，那么我们可以只把它们移动到角落。如果我不得不将所有东西都打包装车，我可以把车送到城里去。这并不是一个大麻烦。最大的麻烦是打包所有的垃圾。无论最终还是否维护或者是放在其它地方，都不是大问题。

David 将 Basecamp 传统版比作莱卡 M3：这款相机于 1967 年已经停产，但是只要他们仍然经营，莱卡至今仍然致力于提供支持与维修。（图片来源：Dnalor 01）

相反，Basecamp 选择致力于“尊重他们的遗产”：他们让用户能够很容易的升级，但是不强制用户弃用 Basecamp 传统版。除此之外，他们还致力于无限期托管、支持和维护 Basecamp 传统版。

四年以后，他们又做了这样的事情：Basecamp 3于2015年发布，从头开始重写，包含了大量特性的移除、添加和修改。和之前的版本一样，旧版本用户可以方便的升级，但是如果他们愿意，用户可以继续使用 Basecamp 传统版或者 Basecamp 2，“直到互联网末日”。

Basecamp 3 不会淘汰任何以前的版本，包括当前 Basecamp 版本和 Basecamp 传统版以及更老的版本。这些老版本系统仍然好用？酷！请继续使用它们，直到互联网末日！我们将会保证每个版本都是顺畅、安全、可靠的。

但是，这样成本是不是很高？难度是不是很大？如何确保安全性？如何处理老版本代码库？这些问题怎么办？我们的想法和做法是照顾好所有顾客，即使他们对我们的升级计划不感兴趣。

经验教训

从我个人角度来说，这个例子是很鼓舞人心的。每次重写都让 Basecamp 能够重新审视设计决策，并构建出他们之前就希望要的产品。

对于用户来说，两方用户都受益：对于不希望动他们已有工程的用户来说什么都没有改变；但是对于之前受限于产品局限的用户来说，可以在一个新的，经过深思熟虑的产品上继续工作。

当然，无限期维护不同版本的产品并不是没有代价的，但是正如 David 说的：

这不是没有代价的。为什么会有人认为这是没有代价的？但这是有价值的，因此即使有代价，也是值得的。

3 Visual Studio 和 VS Code

关键字：时髦的想法

微软为了能够拉拢使用其他平台的用户而开发了 VS Code。

长期以来，开发者的共识是：在微软的世界里，工作是一个 1 和 0 的命题。如果你使用 Visual Studio，那么你会使用.NET，反之亦然。而这将软件社区分裂成两大互斥的阵营，对所有人都是有害的。

向弄潮儿伸手

从 Steve Ballmer 年代，微软开始改变：记得当时ASP.NET团队决定不重写jQuery的时候，是一个多么重大的事情！

随后，吸引微软体系之外的开发者，成为了继任 CEO Satya Nadella 的主要任务之一。

不过正如 Visual Studio 副总裁 Julia Liuson 在Changelog播客中提到的：

我们没有为这类开发者提供任何东西：现代、基于互联网、面向 Node、JavaScript 的开发者。我们之间没有任何共同话题。你们是那些我们永远无法吸引的开发者。

因此开发 VS Code 的动机就是打破这个屏障，并且和你们说，“事实上，你知道吗？我们也有你们可以使用的工具。”

从各个方面来看，Visual Studio 都是一个重量级产品：安装它最长需要耗时半个小时。它必须支持企业级客户的广泛复杂需求。因此，当微软试图通过增加一些特性来吸引其他平台开发者的时候，并没有将 Visual Studio 做为突破口。另外，制作 Mac 或者 Linux 版本的 Visual Studio 的想法基本上也是难以实现的。

因此，微软选择从头开始开发，并且不考虑向下兼容。

当然，VS Code 其实也算不是完全从头开始，微软已经有了一些重要的技术储备，例如基于浏览器的Monaco编辑器。由于 VS Code 也是一个 Node.js 应用（使用 Typescript 语言编写，运行在 Electron 之上），他们也能够利用丰富的 JavaScript 生态。

VS Code 是一个开源、轻量级、快速和可扩展的开发环境，这一产品推出之后就成为了弄潮儿的首选开发环境。

VS Code 成为 JS 潮流追逐者的首选文本编辑器。（图表来源：2018年JavaScript状态调查）

VS Code 和 Visual Studio 两个产品目前都在活跃开发中，且没有任何迹象表明微软将会放弃 Visual Studio。

经验教训

与 Netscape 的教训形成鲜明对比，微软围绕着 VS Code 成功地建立了一个活跃的开源社区。社区成倍的激发了兼职开发团队的激情。

在 GitHub 所有开源项目中，Visual Studio Code 按照星标数排名第 13，仅次于 Linux！

当然，并非每个公司都有这样的商业模式可以支持其核心产品完全开放源码。但是，如果开源是开发策略的一部分，那么这两个公司的案例值得好好学习下。微软为 VS Code 设计了一个坚实的可扩展模型，而社区编写了将近 10000 个扩展。

VS Code 故事的最后一个结论是，最近几年技术发生了根本的改变，使得构建原型和软件变得前所未有的简单。

4 Gmail 和 Inbox

关键字：“日落”

Gmail 的 Inbox 客户端最初被视为原生 Gmail 的用户体验精简版，“设计成专注于用户实际关心的”。它在功能上从未对标原版的 Gmail，并引入了诸如邮件集、固定邮件和延迟消息等功能。

包括我在内的很多人，都踊跃试用了 Inbox。我一直把 Inbox 当成 Gmail 的功能预览版，它缺少一些 Gmail 有的细节功能，我希望这些功能最终能够合并到 Inbox 中。

两套界面，一套服务

Inbox 和 Gmail 都使用相同的后端服务，仅仅是用户界面不同，用户可以随时在二者之间进行切换。这样的设计有利有弊：如果 Inbox 缺少一些功能（例如假期、自动回复），用户可以切换到 Gmail 来使用，但是来回切换会导致一些奇怪的问题。

不过，一段时间之后，Inbox 停止更新，很明显 Google 不再愿意为其投入资源。果然，在发布的 4 年之后，Google 宣布下线Inbox。

刚开始我非常懊恼，但是使用了一段时间最新版的 Gmail 之后，发现许多我喜欢的 Inbox 特性，都已经被移植到了 Gmail 中：智能回复、悬停动作、内联附件和图片等。Gmail 提供的多收件箱功能很好的替代了 Inbox 邮件集。当然，也不是所有功能都有替代产品，例如，打盹功能在 Inbox 下线之后，就不复存在了。

经验教训

Inbox 让 Gmail 团队有了一个实验新特性的平台，而不会打扰现有平台上大量不愿意切换的用户。但是，由于两个应用都使用相同的后端服务，对 Gmail 团队的创新有非常严苛的限制。

Google 因为关闭了 Inbox 服务受到了批评。当然，Google总是在关闭产品，因此我们并不意外。

在这个案例中，Google 围绕着 Inbox 做出的改动，让我们相信我们看到了 Gmail 的未来。但正如 DHH 所说的，这不是美丽的日落，对于许多用户来说，他们被迫放弃 Inbox 的创新工作流，重新回到旧产品当中去。

我认为如果在 Inbox 关闭前，Gmail 已经有和它有同样的功能了，那么用户就会少点抱怨。

5 FogBugz 和 Trello

关键字：悲伤的结局、钱钱钱

FogBugz 是一个特别有意思的案例，因为它是 Joel Spolsky 的产品，它给了我们一个绝对不要重写原则的现实版案例。

在 Jira、GitHub Issue 之前，有一个基于网页的 bug 追踪产品，叫做 FogBugz。它发布于 2000 年，是 Joel 和 Michael Pryor 一起创建的公司 Fog Creek Software 的第一个产品，曾连续 10 年是公司的旗舰产品，最初以热缩包装软件方式售卖，安装在用户自己的服务器上，但是后续也推出在线订阅版。之后就变得非常流行，尤其是在像我这样追随 Joel 的博客并将他的建议铭记于心的开发者人群中。

FogBugz 最初用传统的 ASP 编写，可以运行于 Windows 服务器上。当 ASP.NET 问世时，Joel 解释了他为什么不急于升级。

为了能够让用户将 FogBugz 安装到 Linux 服务器上，一个实习生编写了名为 Thistle 的编译器，将传统 ASP 代码转成 PHP。2006 年，Thistle 进化成了一个私有本土语言，称为 Wasabi，可以编译 ASP、PHP 和客户端 JavaScript。

Wasabi 的奇怪故事

现在，开发一种内部使用的编程语言和编译器是一个很古怪的选择。

一次，Joel 在其一篇博客的末尾段落中描述了Wasabi。很多人觉得他不是认真的，但是他澄清了他的确是认真的。这让他的同事，博主 Jeff Atwood 的脑袋都要炸了：

编写一个自己的编程语言绝对是越界了。这是一个有毒的决定，与 Joel 之前关于软件开发的优秀和理智的建议完全不一致，人们认为他们在开玩笑。

Joel认为这一切都是有商业价值的：当然如果从头开始，我们不可能发明自己的语言。但是如果看整个过程中的每个决定，考虑当时技术背景和代码库，我们能看到最终的结局。

反映到 Wasabi，前 Fog Creek 工程师 Ted Unangst 在一篇题为《技术债和风险》的文章中将这一流程比作没有地图的旅行：

假设我们在佐治亚州的萨凡纳要去英国伦敦。如果手头没有地图，只有一个模糊的方向感。……我们不能走直线，至少在没有船的时候不行，因为两个地方相隔着大海。不过有一个漂亮的沙滩通往东北方向，这正是我们要去的方向。随着时间流逝，我们会发现虽然前进方向不是正对着目的地，但是我们走的每一步都会更接近目的地。

在波士顿或新斯科舍附近，我们最终会停下来思考之前做出的选择。这些也不是去伦敦的路。在花生廊的最高处，我们可以听到大笑声。“哈哈哈，看看这些傻子，分不清英格兰和新英格兰。给这些傻子拿个地图吧。”但是事实是，我们没有地图，而地图正是由那些不知道自己要去哪里的人制作的。

另一个前 Fog Creek 公司开发 Jacob Krall解释道，这个决定是以日后的维护成本来提升当前的开发效率。这也是技术债的定义，到 2010 年，这笔技术债需要到期偿还了。

我们没有开源（Wasabi），因此对其所有的投入都需要我们自己完成，这样做的代价是牺牲主要创收产品。……这是一个巨大的依赖，需要一个全职开发者，这对于我们这个规模的公司来说是不小的成本。有时候它会无法处理一段在人们看来很正常的代码，编译速度很慢。我们无法使用 Visual Studio 方便的编辑和 debug FogBugz。……所有新人不论之前有什么经验，都需要付出很大的成本来学习 Wasabi。……另外，我们不是生活在真空中，编程语言在 Fog Creek 公司之外也一直在提升。……开发者开始觉得他们的好想法会因为我们 Wasabi 小天地的约束而无法实现。

一个拐点

在这十年中，FogBugz 是一个成熟稳定的产品。Joel和Jeff Atwood一起以辅助项目的形式创立了Stack Overflow。

而 FogBugz 并没有火起来，反而有点日薄西山。Bug 追踪市场仍然碎片化，在 FogBugz 发布的几年后，Atlassian 的 Jira 发布，并成为用户，尤其是大型企业用户的默认选择。

我对于 Fog Creek 公司这个转折点很好奇，与 Basecamp 类似，他们有一个盈利且成熟的产品，但是功能已经不再吸引新用户。不论是好是坏，它都体现了多年来为了解决特定问题域的技术发展和思想转变。

当然解决思路也可以参照 Basecamp：吸收 Fog Creek 在 bug 追踪领域的成果，从头开始重写 FogBugz。至于为啥没有采用这个思路，我猜原因可能是“这是永远不能做的事情”、“最大的战略性错误”等等等等。

最近，我发现了一篇 2009 年 Joel 在为 Inc 杂志撰写每月专栏时发表的文章。在这篇题为《缓慢增长等于缓慢灭亡吗？》的专栏文章内容中，Joel 一改之前自信夸张的风格，文章内容充满了反省、不确定和质疑，他在对 Atlassian 的快速发展感到烦恼，担心到最后 Bug 追踪市场是否会只能容下一个产品。

我不得不担心。我们在市场上有一个巨大的竞争对手，而且他们的增长速度比我们要快。该公司正在与大型企业客户达成交易。……明明我们的产品更好、公司运作更良好，为什么这些没有吸引到客户？

所以他决定做两件事情。首先，为 FogBugz 添加更多功能：

这是开发团队 2010 年的目标：消除客户购买我们竞争对手破烂产品的任何可能理由，优势可能是因为非常小的功能点，客户就会说没有它们就无法使用。坦白的说，我不认为这个很难做到。

其次，建立企业销售队伍。Joel 坦言这不是他擅长的，并且让他自己觉得反感。

我不知道后来这两个计划实施的怎么样。Joel 最后一次在他的博客中提到 FogBugz 是几个月后一次很敷衍的小版本发布。

新的希望

后来发生了一件事情：

在 Fog Creek 软件公司十周年纪念日到来之际，我开始考虑如果要让我们的雇员在下一个十年继续保持兴奋和激情，我们必须要做一些新的东西。

因此他们将团队拆分成 2 个，每个团队各自讨论出一个新产品原型。获胜的想法受到了看板的启发：它经常用于软件开发流程，通常是一个划了很多列的白板，每一列都贴有很多便利贴。

Joel 将其作为一个用于管理比 FogBugz 更上层工作的工具：

老实说，市面上所有那些非常花哨的“项目管理”软件，我从来没有找到一个能够追踪谁在做什么事项。……作为两个公司的创始人，在走廊里面看到几十个雇员坐在电脑前，我就会分心……我无法知道他们做的是不是正确的事情，或者在他们看来是重要的，实际上并不重要的事情。

通过构建 Trello，Fog Creek 的开发者有机会开始尝试新的技术：

使用尖端技术，通常也意味着受伤。我们的开发人员在 MongoDB、WebSockets、CoffeeScript 和 Node 上都受过伤。但是至少他们得到了乐趣。在当今严峻的就业市场中，优秀的程序员很在乎他们实际要开发的产品。如果你能给他们一个优秀的产品，他们会感到愉快，并热爱这份工作。

同时，Trello 还在一开始就引入了第三方插件功能，提高内部开发团队效率：

API 和插件架构是最高优先级的。……如果可以通过暴露基本 API 让上层用户帮助我们实现的功能，那么绝对不内置实现。对于 Trello 团队，任何可以通过插件实现的功能，都以插件的形式提供。

当然，程序员立即看见了 Trello 的实用性，但是这个工具并不是只限定于软件开发领域。Joel 将其用途描述为“任何你想要和一群人一起维护一个列表的场景”。Trello 很快被用来组织各种事项，从每周食物到婚礼到动物收容。

如果说 FogBugz 是一个垂直产品：定位于特定市场，那么 Trello 是一个可以用于任何场景的横向产品。Joel 认为，在这个关键时刻，“走向横向”对于 FogBugz 来说是一个正确选择：

开发一个任何行业都能够使用的横向产品几乎是不可能的。我们不能收费太高，我们正在和其他横向产品竞争，它们可以通过巨大的用户量来分摊成本。这样的产品是高投入高回报的：因此不太适合初创团队尝试，但是对于像 Fog Creek 这样成熟、稳定的公司，作为其第二、第三个产品是一个不错的选择。

为了能够快速吸引大量用户，Trello 刚开始是免费的。后续才推出了付费的“商业级”功能。

2014 年，Trello剥离出来成为独立的公司。三年后，拥有 1700 万用户的Trello以4.25亿的价格被收购。具有讽刺意味的是，买家是 Fog Creek 的老克星 Atlassian。

同时回到大本营

Fog Creek 又开发了另一个新产品，一个协作编程环境，最初被命名为HyperDev，然后改名为GoMix，最终被重命名为Glitch。

与此同时，FogBugz 也在默默无闻中慢慢萎靡。2017 年有人觉得 FogBugz 是一个愚蠢的名字，想将这个产品品牌重塑成Manuscript。一年后，Fog Creek 将这个产品卖给了一个名为DevFactory的小公司，产品名称被迅速被改回了FogBugz。

在 CEO Anil Dash治下，Fog Creek 成为了单一产品公司，并更名为Glitch。

经验教训

我对此有很多感触：整个故事的关键在于 Fog Creek 公司的目标不是开发 Bug 追踪软件，而是增加程序员的自主权：

建立一个好的工作场所是我们的首要目标。我们有私密的办公室，出差坐头等舱，一周工作 40 个小时，为员工提供午餐、Aeron 的椅子和顶配电脑。我们的理念是：优秀的办公条件 → 优秀的程序员 → 优秀的软件 → 利润！

脑袋里有了这个“公式”之后，我们或许可以把之前那些令人鼓舞的故事串联到一起：Fog Creek 围绕着开发者幸福感构建了一个商业。这从该公司产品和内部“操作系统”中都能体现出来。它的最初产品是一个 Bug 追踪软件，为后续推出用更加普适方式解决类似问题的产品奠定了基础。

我认为，按照 Joel 自己所说，Trello 最初并不是 Joel 为了找到新的商机，而是寻找一个让 Fog Creek 的开发人员感到开心和充实的方式**，反而意外的创造了一个价值 5 亿的产品。

不过，我不禁对 FogBugz 的结局感到难过，我不认为这个产品的开发者在 Fog Creek 最后一段时间里会感到快乐。

很明显，以下这些项目的参与者有更大的收获：Stack Overflow、Trello 和 Glitch 每个产品都远比 FogBugz 有用和有价值。但是，任何一个人只能用他们的时间做这么多。因此，我不能羡慕那些因为 FogBugz 有 20 年历史的代码和处于激烈的市场竞争中而对 FogBugz 失去兴趣的人。至少它的忠实用户还有一个家，并且没有受到“日落”的待遇。

但是，令我感到伤感的是，对于所有创造和使用了多年产品的人，希望能有一种更好的方式来“尊重遗产”。

6 FreshBooks 和 BillSpring

关键字：秘密行动

关于 FreshBooks 和 BillSpring 的小故事

在 2000 年早期，Mike McDerment开了一家小型设计机构。当时他使用 Word 和 Excel 来制作发票，因为他觉得当时的会计软件对他来说都太复杂了。

有一天我在保存一个重要客户发票的时候发生了意外，这使我很抓狂。因此，我下定决心要避免这种意外，我花费了 2 个星期来编码，而这成为了现在 FreshBooks 的原型。

Mike 是一个设计师而非程序员，但是他和另外两个联合创始人完成了一个适用于少数人群的工具，定价 $10 一个月，而这项业务让他花了将近4年时间才离开他父母的地下室。

在 FreshBooks 10 周年之际已经有了稳定的盈利，它有超过 1 千万用户和 300 多雇员。

这里有一个问题：当他们有能力雇佣“真正的”程序员的时候，“创始人代码”已经超过百万行了，一个外部分析师审查了他们的代码之后总结道：

好消息是你们已经解决了最困难的问题。你们找到了一个构建商业的方式，并且创造出了用户喜爱的产品。坏消息是你们的技术糟透了。

更重要的是，他们有新的想法，但是现有产品无法实现：

我们在十多年前创办了这个公司，世界正在发生变化，我们学到了很多关于构建产品和服务用户的方法。在这其中自雇专业人士和他们的团队是不断增长的客户。……对于 FreshBooks 来说，要能够保持节奏并在未来的五年中继续服务好这群人，我们需要作出改变。

McDerment吸收了关于从头重写软件的普遍认知：

对于软件公司来说没有什么比重写有更高风险的了。你甚至有可能无法完成这个项目。它将会花费远大于预计的时间和其他开销。而且重写了之后，客户还不一定会喜欢它。同时无法保证新的平台是一个更好的产品。软件开发领域的首要规则是不重新平台化软件。

因此他们做了很多尝试来清理现有代码，但是发现为“正在行驶的车更换轮胎”是不可能的。

接下来发生的事情可能会惊到你

McDerment 最后想到的办法是秘密创建一个 FreshBooks 的“竞争对手”。

他在特拉华重新创建了一个名为 BillSpring 的新公司。新公司有自己的域名、品牌和商标。为了防止被人发现这两家公司的关联，他还请外部律师起草了新的服务条款。

新公司开发团队将Jeff Gothelf和Josh Seiden的书《精益设计 设计团队如何改善用户体验》作为他们的指南，并实施敏捷实践，例如实施 Scrum 团队、每周迭代并与真实客户一起组织回顾会议。McDerment 告诉他的团队将公司视为初创团队，将他视为风投：

“你们有四个半月时间。如果到时间能够投入市场，我们将会给你们更多的钱；反之我们就撤资。”

这个团队在截止日期前几天完成了最小可行产品（minimum viable product，MVP）。他们通过购买 Google AdWords 来为新网站引流，并且第一年提供免费帐号。不久之后，新产品就有了真实用户，同时他们开始快速迭代润色产品。

当产品发布一年后，他们开始向用户收费。新产品以意想不到的方式得到了认可：

“一个客户给我们打电话取消 FreshBooks 订购，告诉我们他们将要使用新公司的产品”，McDerment 说：“这是美好的一天。”

不久之后，他们揭开了神秘的面纱：他们告知 BillSpring 客户他们在使用的产品就是 FreshBooks，同时让 FreshBooks 的客户知道新版本即将上线。

慢慢的，“FreshBooks 经典版”客户被邀请尝试新的版本，但这不是强制的，如果需要，用户可以随时迁移回他们熟悉的老版本。

经验教训

FreshBooks 的秘密重写成本并不低：McDerment 估计这个项目花费了$700万。经过了十多年的增长，他们刚刚收到了$3000 万的风险投资，因此他们有能力去做重写，但并不是所有人都有这样的资金能力。

福布斯估计 2013 年 FreshBooks 的收入为$2000万。到了2017年完成升级之后，他们的收入为$5000 万。虽然，公司没有指明其中有多少增长来自于新产品，但至少这次重写没有减缓公司的增长。

McDerment 称他们现在有能力更快速和方便的新增功能。更重要的是，这个面向未来的产品融合了他们最好的想法。除了他们的既定目标之外，他们的经验还正向改变了公司文化。他们假装成创业公司的时间让他们更像创业公司。他们实施的“精益”实践传播到了整个工程师团队。客户也紧密的参与到新功能的开发中。

FreshBooks 在努力将自己与重写潜在的不利因素隔离开来：通过抛弃现有品牌，开发者可以完全自由的重新思考，但同时也要承担更大的风险。这样，他们最坏的结果是新产品开发失败，而这至少不会影响现有的品牌。

这个故事比较极端，对于一般企业来说，可能没有必要像他们这样做。

最后的一些思考

关于重写软件的一般常识是，通常情况下应该避免重写，而是通过增量改进的方式来代替。我基本上认同这个观点，但是这要建立在重写的最终目标是在原始产品上增加一些新需求。

但是如果我们想要移除功能呢？或者我们想要用完全不同的方式来解决一些用例呢？亦或是我们对产品的经验给了我们全新的实现方式？

我对这些故事的看法是：一旦我们足够了解设想的产品终局和当前版本的差距非常大时，那么最佳的做法是不要用新的版本来替换当前软件，而是重新构建一个新的，但是不要抛弃已有的代码。

因此，当我们在思考是否需要重写时，其实我们应该重新审视下自己的产品并问自己：我应该创造一个自己竞争对手吗？如果我的产品是 FogBugz，什么是我的 Trello？如果产品是 Visual Studio，我的 VS Code 应该长什么样？

如果我们重新把Spolsky关于Netscape的文章和DHH关于Basecamp的文章放一起来看，我们会发现他们在一件事情上是有共识的：我们已经创造的东西是有价值的，我们不必为了创新而抛弃这些价值。

原文链接：Lessons from 6 software rewrite stories