软件开发失败的原因（编码一时爽重写火葬场）

作者 | Herb Caudill

译者 | 无明

生存，还是死亡，这是一个问题。重写，还是不重写，这是导致生存或死亡的另一个问题。

这是一个很老套的问题：你应该重写应用程序吗？又或者这是“任何一家软件公司都会犯的一个战略性错误”？或许，对于一个已经很成熟的代码库来说，这并不是一个二选一的问题。

大约 20 年前，Joel Spolsky 在他的文章“Things You Should Never Do”中对网景公司重写 NETscape 代码库的行为进行了一番痛斥。

他认为，永远不要重写功能性应用程序，因为：

• 应用程序代码库中那些看起来很粗糙的部分通常包含了与各种边界用例和奇怪 bug 相关的信息，而这些信息通常是得之不易的。
• 重写应用程序是一项非常耗时的工作，它不仅无法让你改进现有的产品，而且在此期间，竞争对手可能借机向你逼近。

对于大多数人来说，Jole 的观点成为了某种信条。我也承认，那个时候我在很大程度上也受到了他的观点的影响。

在接下来的几年，我听到了一些不同的观点。这些观点认为，在某些情况下，重写应用程序也是有意义的。例如：

• 有时候，遗留代码库确实混乱到无法理清楚，即使是最简单的变更也需要对代码的其他部分进行级联变更。
• 最初的技术选型可能会阻碍你改进系统。
• 最初的技术可能已经过时，招聘高质量的开发人员变得很困难（或者成本很高）。

当然，正确的答案是，这在很大程度上取决于实际情况。有时候逐步重构遗留代码会更有意义，而有时候把旧代码扔掉并重新开始会更有意义。

但这并不是唯一的选择。让我们来看看下面的六个故事，看看能够从中吸取到什么教训。

Netscape Navigator 最早是在 1994 年发布的，在发布不到两年之后，网景公司以 30 亿美元的 IPO 开启了互联网时代。

Netscape 的第一个真正竞争对手是微软于 1996 年推出的 IE 浏览器。

1998 年初，Netscape 仍然是领先的浏览器，但只是勉强领先。Netscape 的零售价为 49 美元，而微软免费赠送 IE，并将其作为默认浏览器与 Windows 一起发布。

在发布 Netscape 4.0 之后，网景公司宣布将免费提供 5.0 版本，并由公司资助的一个叫作 Mozilla 的开源社区负责开发。

这在当时基本上是史无前例的，网景公司因为这个大胆的举动赢得了人们的尊重。然而，社区并没有真正兑现之前的承若。Jamie Zawinski 是该浏览器最早的开发者之一，他解释说：

事实上，由于 Mozilla 项目的贡献者包括大约 100 名全职 Netscape 开发人员和大约 30 名外部兼职开发人员，所以这个项目实际上仍然完全属于网景。

该团队得出的结论是，外部开发人员之所以对这个开源项目不感兴趣，是因为现有的代码库太乱了：

代码太复杂，太粗糙，难以修改，人们甚至无法添加新代码，这也就是为什么我们要切换到新的代码库。从理论上讲，一个更干净的新代码库更容易让人们理解，也更容易让他们贡献代码。

从头开始

一年后，这个小组决定放弃 5.0 版本，并从头开始开发 6.0 版本。

又过了两年，Netscape 6.0 终于发布了。但即使经过了这么长时间，它仍然没有为发布做好准备。《纽约时报》评论员 David Pogue 说，光是启动就要花一分钟时间，不仅占用了很大的内存，而且缺少前几代浏览器的一些简单功能。

但这些还不是最重要的。在 Netscape 停滞不前的三年中，IE 已经抢占了所有剩余的市场份额。

1999 年，当重写工作还在进行当中的时候，AOL 以 100 亿美元的价格收购了网景公司。

在 Netscape 6.0 发布两年之后，AOL 内部的 Netscape 团队就被解散了。

Mozilla 继续在 2002 年发布了 Firefox 浏览器——这又是又一次彻底的重写。不过 Firefox 确实设法从微软手中夺回了一些市场份额。

但作为一家企业，网景已经死了。令人难堪的是，在 2012 年与 AOL 达成一项协议后，微软最终拿走了网景剩余的知识产权。

在赢得这场战斗之后，微软减少了对浏览器技术的投入。IE 6.0 于 2001 年发布，此后 5 年没有再进行升级，一些人认为微软是有意这么做的，目的是阻止 Web 平台的发展。

学到的教训

人们认为，从长远来看，重写并不一定是一场灾难，因为这个项目最终催生了 Gecko 引擎和 Firefox 浏览器。

但多年来，在等待新浏览器出现的过程中，因为 IE6 无休止的垄断，我们不得不忍受 Web 技术的停滞不前。但最终终结 IE6 时代的并不是 Firefox，而是谷歌 Chrome。

不管如何，现在的问题并不是说重写对 Web 是否有好处，而是从公司的角度来看这是不是一个好的决定。网景的衰落并不完全是因为重写——法院认为是微软滥用了他们的垄断地位。

但重写仍然是一个促成因素，最终的结果是毁掉了一家价值数十亿美元的公司，并裁员数千人。所以，我同意 Joel 的观点，这次重写的结果是灾难性的。

2. Basecamp

2000 年代早期，芝加哥的一家名为 37signals 的网页设计公司因为其创始人 Jason Fried 和 David Heinemeier Hansson 的影响力而获得了一批追随者。

2004 年，他们开发了一个供内部使用的项目管理工具，并将其作为一款 SaaS 服务对外发布，名为 Basecamp。

那个时候，订阅软件还是一个很新鲜的东西。项目管理工具被装在包装盒里，外面贴着四位数的价格标签，还有厚厚的手册，全都是关于如何建模关键路径和生成复杂的甘特图。

Basecamp 的售价为每月 50 美元，它的界面超级简单，十分注重沟通效果，给人耳目一新的感觉。

几年之后，Basecamp 的用户达到了 50 万，每月都有支票滚滚而来，但 Jason 和 David 开始感到焦躁不安。

几年前，我在软件行业大会上听到 David 讲述了这个故事。他说，他不仅相信 Joel Spolsky 所说的重写软件会毁掉公司，而且敏捷运动还激发了他的某种自以为是：

我完全被卓越软件的理念所吸引。那些代码是无限可塑的，遗留代码是无价之宝。你可以改变任何东西，任何软件，任何代码都可以重写。如果软件很难被修改，那是你的错。你是一个糟糕的程序员，你必须学会变得更好。

然而，在他所谓的“七个丰收年”之后，他们陷入了困境——而这一切与技术债务无关。

黄金手铐

他们开始发现自己的热情开始在消退。他们不仅没有动力去开发旗舰产品，就连他们自己也不怎么使用自己的产品。

他们有很多关于如何从根本上让产品变得更好的想法，但因为已经有成千上万的用户在 Basecamp 上构建了他们的工作流，他们所做出的每一个变更都会对很多人造成破坏性影响。这个时候，给改变造成阻碍碍的不是粗糙的代码库，而是用户。

为了让现有的客户满意，他们等于是冻结了产品，无法吸引到新客户。这对公司来说不是一个迫在眉睫的问题，而是一个长期的威胁。

部分问题在于，你只能从现有的客户那里听到他们的心声，却无法从未来客户那里听到任何东西。

他们开始意识到，他们的产品成了一套黄金手铐。

他们开始重写 Basecamp，结果非常棒。他们花了大约一年的时间，在 Basecamp 2 发布后，新注册用户立即翻了一番。

他们做了两件有趣的事，我认为这就是他们取得成功的原因。

首先，他们没有试图重建已有的产品，因为他们对要解决的问题有了新的想法。

他们把 Basecamp 2 作为一个全新的产品，而且不保证它能够向后兼容 Basecamp Classic。有很多东西是新的，有一些东西被去掉了，还有很多东西变得完全不一样。

这个决定给了他们一定程度的自由。自由是一种动力，而有动力的人会做得更多。

淘汰旧产品的危害

那么其他数十万现有用户该怎么办呢？因为动了他们的奶酪，所以他们怨声连天。

这就引出了他们做的第二件有趣的事请，他们并没有淘汰旧产品。

David 指出，如果你强迫用户打包走人，就犯了“有史以来最严重的战略性错误”：因为如果这样，这些用户就会考虑是继续使用你的软件还是干脆转移到别的地方去。

Basecamp 选择“尊重他们的遗留用户”：他们简化了用户的升级路径，而且不要求他们一定要离开 Basecamp Classic。不仅如此，他们还承诺将继续无限期地支持和维护 Basecamp Classic。

更令人感到惊喜的是，四年之后，他们又重头来过：他们在 2015 年发布了 Basecamp 3，这也是一个重写版本，删除了一些旧功能，添加了一些新功能，并且做出了很多改变。和以前一样，老版本用户可以轻松升级——但如果他们愿意，也可以继续使用 Basecamp Classic 或 Basecamp 2，“直到互联网结束的那一天”。

学到的教训

在我看来，这种模式非常具有启发性。

每一次重写都是在重新审视 Basecamp 的设计决策，并让他们有机会构建之前希望构建的产品。

对于用户来说，不希望发生改变的用户可以保持原地不动，而希望使用新功能的用户可以使用一个全新的、更好的、经过深思熟虑的产品。

但无限期地维护产品的多个版本并不是没有代价的，正如 David 说的那样：

这绝对不是免费的。你为什么会希望它是免费的呢？它其实很有价值，所以当然不是免费的，但这么做是值得的。

3. Visual Studio 和 VS Code

微软开发 VS Code 是为了吸引其他平台上的开发者。

在很长一段时间里，在微软的世界里工作就像是一个硬币的两面。如果你使用 Visual Studio，那么就是在做.NET 开发。反过来，如果你做.NET 开发，那一定在使用 Visual Studio。这将软件社区分成了两大相互排斥的阵营，对任何一方都不是很有利。

吸引墙外那些很酷的人才

即使是在 Steve Ballmer 时代，这种情况就已经开始发生变化。还记得 ASP.NET 团队决定不再重新发明 jQuery 吗！

不管从哪一方面来看，Visual Studio 都是一个重量级的产品：安装它可能需要半个多小时。它必须支持企业客户所依赖的各种复杂用例。因此，如果微软试图通过添加特性来吸引其他平台的开发者，那么将 Visual Studio 作为起点是毫无意义的。而且，开发 Mac 或 Linux 版本的 Visual Studio 的想法也是不切实际的。

所以，微软从零开始，并且不保证向后兼容性。

实际上也并非完全从零开始：微软已经有一些现成的东西，比如 Monaco 编辑器。因为 VS Code 是一个 Node.js 应用程序（用 Typescript 开发，运行在 Electronic 上），所以他们可以利用丰富的 JavaScript 生态系统。

VS Code 是一款开源、轻量级、快速和可扩展的编辑器，而且令人感到惊讶的是，作为一款微软的产品，它已经成为很多开发者的首选编程环境。

这两款产品都还在积极开发中，而且没有迹象表明微软会打算停止 Visual Studio 的开发。

学到的教训

与 Netscape 形成鲜明的对比，微软成功地围绕 VS Code 构建了一个活跃的开源社区。

当然，并不是每家公司都会有一个可以完全支持开源其核心产品的业务模型。

但是，如果开源是公司开发策略的一部分，那么就值得通过比较这两个案例找出微软做了哪些不一样的事情促成了社区的繁荣。

另外，微软还为 VS Code 提供了一个可靠的扩展模型，社区已经开发了近 10,000 个插件。

在过去几年里，事情发生了根本性的变化，软件的开发和原型创建比以往任何时候都更容易。

尽管人们都对当今开发工具集的复杂性感到绝望，但事实是，JavaScript 生态系统在过去几年里已经发展成为人们期待已久的可重用、模块化的开源乐土。从这方面来看，这是一个史无前例的时代。

4. Gmail 和 Inbox

Gmail 的 Inbox 最初是作为 Gmail 的精简版 UX 引入的，“旨在关注真正重要的东西”。它从未具备与原始 Gmail 相同的功能，但引入了捆绑、固定电子邮件和待处理消息等新功能。

包括我在内的一些人对 Inbox 很感兴趣。我一直以为 Inbox 是 Gmail 最终会成为的东西，所以忍受着它缺少 Gmail 的一些功能，并期望最终会在 Inbox 中增加这些功能。

两个界面，一个服务

Inbox 和 Gmail 都使用了相同的后端。它们本质上只是相同服务的不同用户界面，你可以随意来回切换。这既有好处也有坏处：如果 Inbox 缺少了某个功能（比如假期自动回复），你可以回到 Gmail 做你需要做的事情。但来回切换难免会觉得有点奇怪。

然而，过了一段时间，Inbox 停止改进，而且很明显，谷歌不再为其投入任何资源。果然，在推出四年之后，谷歌宣布将关闭 Inbox。

我最初感到非常恼火，但在花了一点时间研究了最新版本的 Gmail 之后，我发现 Inbox 中许多我最喜欢的功能都被移植到了原始产品中：智能回复、悬停操作、内联附件和图像。Gmail 的多收件箱也是 Inbox 捆绑的一个很好的替代品。

但并非一切都很完美：例如，待处理消息已经成为很多人处理电子邮件的一个关键部分，Inbox 的消失让他们感到无所适从。

学到的教训

Inbox 让 Gmail 团队可以在不中断工作流程的情况下，为那些不切换视图的绝大多数用户试验新功能。

然而，因为使用了相同的后端，Gmail 给自己的创新能力设置了严格的限制。

谷歌再次因为关闭了一项广受欢迎的服务而受到指责。当然，关闭产品对谷歌来说已经是家常便饭了，我们还能期待什么呢！

在这个案例中，Inbox 让我们相信我们看到了 Gmail 的未来。这绝对不是一次完美的退出，很多人不得不重新使用旧产品，并且失去了 Inbox 的创新，这是很糟糕的。

我认为，如果 Gmail 在关闭 Inbox 前就具备 Inbox 的所有功能，人们的不快或许就会少一些。

5. FogBugz 和 Trello

FogBugz 是一个特别有趣的案例，因为它是 Joel Spolsky 的产品：它向我们展示了永不重写软件的原则如何体现在实际的产品中。

在 Jira 和 GitHub Issues 出现之前，有一个基于 Web 的 bug 跟踪产品，叫作 FogBugz。它于 2000 年发布，是 Fog Creek 软件公司的第一款产品。这家公司是由 Joel 和 Michael Pryor 共同创办的，这款产品也是他们十多年来的一款旗舰级产品。他们最初只将其作为打包软件出售，可以安装在用户自己的服务器上，但后来又推出了一个托管的订阅版本。

它开始变得非常流行，我的公司也用了它很多年。在当时，它是一款伟大的产品。

FogBugz 最初是用 ASP 开发的，运行在 Windows 服务器上。在微软推出 ASP.NET 的时候，Joel 解释了为什么他不着急升级。

https://www.joelonsoftware.com/2002/04/11/our-net-strategy/

为了让人们能够在 Linux 服务器上安装 FogBugz，一名实习生开发了一个叫作 Thistle 的编译器，将 ASP 转成 PHP。到了 2006 年，Thistle 发展成为一门私有的编程语言，叫作 Wasabi，可以将代码编译成 ASP、PHP 和客户端 JavaScript。

一个转折点

FogBugz 在 10 年的时间里已经发展成一款成熟而稳定的产品。

但 FogBugz 并没有把世界点燃，反而显得有点老态龙钟。虽然 bug 跟踪系统的市场仍然很分散，但 Atlassian 的 Jira——比 FogBugz 晚推出几年——已经成为大型企业用户的首选。

我对 Fog Creek 公司发展史上的这个转折点感到非常好奇。和 Basecamp 一样，他们也有一款可以盈利的成熟产品。但它不再性感，可能也不怎么令人感到兴奋。无论是好是坏，它都体现出了多年来技术的变革以及关于如何解决特定问题的想法演变。

当然，一种应对方法是像 Basecamp 那样：Fog Creek 可以利用学到的有关 bug 跟踪系统的所有知识来重新开发 FogBugz，从头开始。

不过我猜这个想法并没有走得太远……

最近，我看到了 2009 年的一篇文章，当时 Joel 正在为 Inc 杂志撰写月度专栏。这个专栏叫作“缓慢增长是否等于缓慢死亡？”，与他以往那种自信的夸夸其谈截然不同：变成了一种内省、试探和怀疑。Atlassian 的快速增长让他感到担忧——他很想知道在 bug 追踪系统市场上，最终是否只会剩下一款产品。

所以他决定做两件事情。首先，将所有功能添加到 FogBugz 中。

第二，建立企业销售团队。Joel 承认这不是他擅长的事情，其实他很讨厌做这样的事情。

我不知道这两个计划的结果如何。Joel 最后一次在他的博客上提到 FogBugz 是几个月后的一个小版本发布声明。

新的希望

事情是这样的：

大约在 Fog Creek 软件公司成立 10 周年之际，我开始在想，如果我们想让员工在接下来的 10 年里保持兴奋和动力，就需要做一些新的东西。

因此，他们把团队分成了两组，每个小组都要想出一个新的产品创意，并构建出原型。

获胜的想法受到了看板的启发。看板是一种物理工具，被用在软件开发中，通常会在白板上粘贴便利贴，并在不同的栏位之间移动这些便利贴。

Joel 将其描述为一种用于管理更高级别的任务的工具。

在开发 Trello 的过程中，Fog Creek 的开发人员有机会使用新技术替换旧技术：

我们开始使用尖端的技术。通常，这意味着一定会割到自己的手指。我们的开发人员在 MongoDB、WebSockets、CoffeeScript 和 Node 上鲜血满布，但至少他们玩得很开心。如果你能让他们去开发一款令人兴奋的产品，他们会很开心，也会对他们的工作充满热爱。

Trello 还启用了第三方插件，这成倍地增加了内部开发团队的工作量。

当然，程序员们马上就看到了 Trello 的实用性，但是这个工具并没有任何特定于软件开发的东西。很快，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 将 Manuscript 卖给了一家叫作 DevFactory 的小公司，这家公司立即又把名字改回 FogBugz。

在 CEO Anil Dash 的领导下，Fog Creek 成为一家只提供单一产品的公司，并更名为 Glitch。

学到的教训

这个故事的关键点在于，Fog Creek 关心如何为程序员赋能多过关心 bug 跟踪系统本身——从他们自己的程序员开始：

为程序员创造一个好的工作环境是我们的首要目标。我们有私人办公室，出差坐头等舱，每周工作 40 小时，为员工买午餐、人体工学椅和顶级电脑。我们的公式是：伟大的工作条件造就伟大的程序员，伟大的程序员造就伟大的软件，伟大的软件为我们带来利润！

有了这个“公式”，我们就可以把这一切连成一个完整的故事：Fog Creek 为开发者的幸福打造了一家企业，这可以从公司的产品和内部“操作系统”反映出来。

我认为，从 Joel 讲述 Trello 起源故事的方式来看，重点并不在于寻找新的商业机会，而在于寻找一种可以让 Fog Creek 的员工开心工作的方法。创造一个价值 5 亿美元的产品只是一个令人愉快的意外结果。

但我还是忍不住为 FogBugz 的结局感到难过。我认为在产品的最后阶段不会有多少人会感到开心。

很显然，所有人都有更重要的事情要做：Stack Overflow、Trello 和 Glitch 都比 FogBugz 更有用、更有价值。所有人的时间都是有限的。因此，我不会因为任何人对 FogBugz 失去兴趣而感到惋惜，因为 FogBugz 拥有 20 年历史的代码库和竞争激烈的利基市场。至少它的忠实用户最后找到了一个安身之处，没有落得“日落西山”的下场！

但从情感方面讲，我希望能够有一个更好的方式来“纪念”这些年来创造这个产品和使用这个产品的人。

6. FreshBooks 和 BillSpring

2000 年代早期，Mike McDerment 拥有一家小型的设计公司。他认为会计软件太过复杂，所以就用 Word 和 Excel 来管理票据。

但终于有一天，这种方式不再奏效了：

有一天，我不小心弄丢了一份重要的客户票据，这让我感到很崩溃。我知道肯定有更好的方法，所以接下来我花了两周时间写了一些代码，这些代码为 FreshBooks 的诞生奠定了基础。

Mike 是一位设计师，而不是程序员，但他和两位联合创始人设法拼凑出了一个足够好的工具，有人愿意每月花 10 美元使用它。他花了将近四年的时间才把生意做到让他有能力从父母的地下室搬出来。

在这款产品推出 10 周年之际（这听起来是不是有点耳熟？），FreshBooks 已经赚到了丰厚的利润，拥有 1000 多万用户和 300 多名员工。

但有一个问题：在他们开始雇佣“真正”的程序员之前，他们已经有一百万行“创始人写的代码”。一名外部分析师审查了他们的代码库，并得出结论：

“好消息是，你们已经解决了最困难的问题。你们已经知道如何创办一家企业，拥有一款人们喜爱的产品。坏消息是，你们这些家伙的技术太烂了”。

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

我们在十多年前创办了这家公司。但世界已经变了，我们学会了如何开发产品以及如何为那些为自己工作的人提供服务。自主创业的专业人士和他们的团队是劳动力大军中一个庞大且不断增长的部分……为了让 FreshBooks 能够跟上时代的步伐，并能够在五年内很好地服务于这个群体，我们知道我们需要采取行动。

McDerment 借鉴了如何从头来过的一些传统思维：

对于软件公司来说，没有什么东西能够比重写软件具备更大的风险了。你甚至很可能无法完成这个项目。这比你想象的要花更长的时间，花更多的钱。你可以这么做，但用户可能不会那么喜欢。而且，建立一个新平台并不一定会得到一个更好的产品。软件开发的第一原则是不要重构软件的平台。

因此，他们做了几次尝试，试图在不从头开始的情况下收拾残局，但他们发现“在行驶的车子上换轮胎”是不可能的。

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

McDerment 最后想到的主意是秘密推出一个 FreshBooks“竞争对手”。

他在特拉华州成立了一家叫作 BillSpring 的新公司。新公司有自己的网址、品牌和 logo。为了避免这两家公司被联系在一起，他让一位外部律师起草了新的服务条款。

开发团队将 Jeff Gothelf 和 Josh Seiden 共同撰写的“Lean UX: Designing Great Products with Agile Teams”作为开发指南，并采用了敏捷实践，如 Scrum 团队和每周迭代，并与真正的客户举行评审会议。

McDerment 告诉他们，要把自己想象成初创公司，并把他想象成公司的风险投资者。

“你们有四个半月的时间。如果到时候你们可以进入市场，我们会给你们更多的钱。否则，你们就出局”。

在截止日期前几天，团队终于交付了一个 MVP。他们购买谷歌 AdWords 向新网站导流量。第一年，他们提供免费账户，不久之后就有了真正的用户，他们也开始通过快速迭代来完善产品。

一年之后，他们开始向 BillSpring 用户收取费用。然后一件意想不到的事情发生了：

有人打电话给我们，说要取消 FreshBooks，并说要转向 BillSpring。对我们来说，这是美好的一天。

不久之后，他们揭开了神秘的面纱：他们让 BillSpring 用户知道，BillSpring 其实是 FreshBooks 的，并让 FreshBooks 用户知道，他们很快就会推出新版本。

渐渐地，“FreshBooks Class”用户被邀请试用新产品——他们也可以不接受，如果愿意，他们总是可以回到原来的版本。

学到的教训

FreshBooks 的秘密重写并不是没有代价的：McDerment 估计他们在这个项目上花了 700 万美元。经过十多年的自主增长，他们筹集了 3000 万美元的风险投资，所以他们有充足的资金。但并不是每家公司都有那么多钱可以花。

《福布斯》估计，FreshBooks 在 2013 年的收入为 2000 万美元。2017 年，在升级完成之后，他们赚到了 5000 万美元。他们并没有透露其中有多少增长是来自新产品，但重写产品似乎并没有减缓公司的增长速度。

McDerment 说，他们现在能够更快更容易地往产品中添加新特性。更重要的是，现在的产品可以实现他们对未来的新想法。

然而，除了他们的既定目标，他们发现这种经历也改变了公司文化。他们假装初创公司的那段时光让他们的行为更像一家创业公司。他们的“精益”实践扩展到了整个工程团队。用户密切参与了新功能的开发。

FreshBooks 竭尽全力将自己与重写的潜在负面影响隔离开来：在一个临时品牌之下进行创新，开发人员可以完全重新思考问题，并承担更大的风险。最坏的结果就是他们会走到另一个死胡同，但至少不会在这个过程中对现有的品牌造成任何损害。

我的一些想法

传统观点认为应该尽量避免重写软件，而是进行增量式的改进——除非由于某种原因无法这么做。

到目前为止，我还是同意这一观点。

不过，这个观点假定了我们的最终目标是得到原始产品加上新功能的组合。

但如果你想要删除一些功能该怎么办？或者，如果你想用一种完全不同的方式解决某个问题呢？如果你通过体验产品获得了一个全新的想法呢？

我从这些故事得出的观点是：如果你已经认识到，在当前产品和理想产品之间肯定存在差距，那么正确的方法不是用一个新产品替换旧产品，而是往旧产品里添加新的东西——不丢弃旧有的东西。

所以，如果你在考虑是否应该重写软件，你应该问问自己：我是否应该给自己制造一个竞争对手？如果我的产品是 FogBugz，那么 Trello 应该是什么样的？如果是 Visual Studio，那么 VS Code 应该是什么样的？

如果你重读 Spolsky 和 DHH 的文章，你会发现他们在一件事情上是保持一致的：已经创造出来的东西是有价值的。

好消息是，你不必为了创新而丢弃这些价值。

英文原文：

https://medium.com/@herbcaudill/lessons-from-6-software-rewrite-stories-635e4c8f7c22

,