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

“好像源代码生锈了。”——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

创作场景

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