重写、重构还是重新发明？
6 个软件重写故事的经验教训
对这个古老问题的新看法：您应该从头开始重写您的应用程序，还是“任何软件公司都可能犯的最严重的战略错误”？事实证明，处理成熟的代码库有两种以上的选择。
大约二十年前，Joel Spolsky 在他具有里程碑意义的文章“你永远不应该做的事情”中斥责 Netscape 重写了他们的代码库。
他的结论是，一个功能正常的应用程序永远、永远都不应该从头开始重写。他的论点围绕两点展开：
- 应用程序代码库中看起来很粗糙的部分通常嵌入了关于极端情况和奇怪错误的来之不易的知识。
- 重写是一项漫长的工作，它使您无法改进现有产品，而在此期间竞争对您有利。
对于许多人来说，乔尔的结论成为了一种信仰。我知道这对我当时的想法影响很大。
在接下来的几年里，我读到一些反对意见，认为在某些情况下，从头开始重写很有意义。例如：
- 有时，遗留代码库确实一团糟，无法修复，以至于即使是简单的更改也需要对代码的其他部分进行级联更改。
- 最初的技术选择可能会阻止您进行必要的改进。
- 或者，原始技术可能已经过时，导致很难（或昂贵）招募到优秀的开发人员。
当然，正确的答案是，这在很大程度上取决于具体情况。是的，有时逐步重构遗留代码更有意义。是的，有时候把它全部扔掉并重新开始是有意义的。
但这些并不是唯一的选择。让我们快速浏览一下六个故事，看看我们可以吸取哪些教训。
（奖励：每个故事的 ASCII 艺术摘要！）
1.网景
网景... 4.0 5.0 ☠ 6.0 7.0 ☠ ⤷ Mozilla 1.0 ☠ 火狐 1.0 ----------
钥匙： = 重写☠ = 死胡同
Netscape 灾难性的 5.0/6.0 重写是“永不重写”的原始海报，感谢 Joel。
Netscape 的 Navigator 于 1994 年首次发布，定义了商业互联网的早期。在发布不到两年后，该公司 30 亿美元的首次公开募股开启了互联网时代。
Netscape 的第一个激烈竞争来自于 1996 年推出的 Microsoft Internet Explorer。
1998 年初，Netscape 仍然是领先的浏览器，但只是勉强。Netscape 的零售价是 49 美元；微软免费赠送 IE，并将其作为默认浏览器随 Windows 一起提供。
Netscape 4.0 版发布后，该公司宣布将免费提供 5.0 版，由该公司创建和资助的名为 Mozilla 的开源社区开发。
这在当时基本上是史无前例的，Netscape 的这一大胆举动赢得了很多好感。然而，碰巧的是，社区并没有真正实现。浏览器最早的开发者之一 Jamie Zawinski解释说：
事实上，由于 Mozilla 项目的贡献者包括大约一百名全职 Netscape 开发人员和大约三十名兼职外部人员，该项目仍然完全属于 Netscape。
该团队得出结论，外部开发人员对为他们的开源项目做出贡献不感兴趣的一个原因是现有代码库一团糟：
代码太复杂、笨拙且难以修改，这就是人们没有做出贡献的原因……这就是我们切换到新布局引擎的原因。从理论上讲，一个更干净、新设计的代码库将更容易让人们理解和贡献。
从零开始
因此，一年后，该小组决定放弃他们在 5.0 上的工作而不发布它，并从头开始开发 6.0 版。
又过了两年，Netscape 6.0 终于发布了。即使过了那么久，很明显它还没有准备好发布。据《纽约时报》的评论员 David Pogue 称，启动 (!) 需要整整一分钟，而且会占用大量内存。而且它缺少前几代浏览器所具有的一些简单的可用性功能：
打印预览功能消失了，将网站地址栏图标直接拖到书签菜单中的功能也消失了。您也无法再通过右键单击地址栏来复制或粘贴网址。每次开始冲浪时，您都必须调整浏览器窗口的大小；Navigator 不记得您上次运行该程序时是如何使用它的。然而，最令人担忧的缺陷是您无法通过单击来突出显示整个地址栏。
这并不重要。在 Netscape 停滞不前的三年里，Internet Explorer 占据了它所有剩余的市场份额：
当重写开始时，Netscape 正迅速被 Microsoft 的 Internet Explorer 击败。三年后，当新浏览器终于发布时，它漏洞百出且速度缓慢；与此同时，Netscape 的市场份额几乎降为零。（图表改编自维基百科。）
1999 年，在重写过程中，AOL 以 100 亿美元的价格收购了 Netscape。
就在 Netscape 6.0 发布两年后，AOL 内部的 Netscape 团队解散了。
Mozilla 是 Netscape 创建的开源社区，在又一次彻底重写之后，将在 2002 年继续发布 Firefox 浏览器。Firefox 确实设法从微软手中夺回了一些市场份额。
但 Netscape 作为一家企业已经死了。（在一个极具讽刺意味的脚注中，在2012 年与 AOL 达成交易后，微软最终得到了 Netscape 的剩余知识产权。）
赢得这场战斗后，微软撤回了对浏览器技术的投资。Internet Explorer 6.0 于 2001 年发布，并在接下来的五年内没有进行另一次升级，一些人认为这是一种蓄意的策略，旨在阻止网络作为应用程序平台发展。
教训
人们争辩说，从长远来看，重写并不是一场灾难，因为该项目最终导致了 Gecko 引擎和 Firefox 浏览器。
但是在我们等待新浏览器获得牵引力的同时，我们都不得不忍受IE6 无休止、令人窒息的垄断下 Web 技术多年的停滞；而最终终结 IE6 时代的不是 Firefox，而是 Google Chrome。
无论如何，手头的问题不是重写是否对网络有利；从做出决定的公司的角度来看，这是否是一个好的决定。Netscape 陷入无足轻重的境地并不完全是因为重写——法院认为微软故意滥用了他们的垄断地位。
但重写肯定是一个促成因素，最终的结果是摧毁了一家价值数十亿美元的公司和数千人的裁员。所以我同意 Joel 的观点，即这次重写的最终后果是灾难性的。
2. 大本营
大本营经典-------------------------------------------- -> 大本营 2 ------------------------------------ -> 大本营 3 -------------------------- ->
在 2000 年代初期，一家名为37signals的芝加哥网页设计公司围绕创始人Jason Fried和DHH颇具影响力且经常逆向的博客建立了一批追随者。
当我刚开始担任网页设计师时，他们最初引起了我的注意，对 Google 和 PayPal 等网站进行了一系列主动重新设计，称为37better。
近 20 年后，37signals对 FedEx 运输表格（左）的重新设计仍然比真实的要好。
2004 年，他们采用了他们为内部使用而开发的项目管理工具，并将其作为名为Basecamp的软件即服务产品发布。
当时订阅软件还很新鲜。项目管理工具装在带有四位数价格标签和厚厚手册的收缩包装盒中，都是关于建模关键路径和生成复杂的甘特图的。
Basecamp 以每月 50 美元的价格出售，界面超级简单，专注于交流，令人耳目一新。
快进几年，Basecamp 拥有 50 万快乐用户，每个月都在收到支票，Jason 和 David 开始变得焦躁不安。
几年前，我在软件业务会议上看到大卫讲过这个故事。他说，他不仅被 Joel Spolsky 说服重写软件会毁掉公司，而且还受到敏捷运动的启发而自以为是：
[我]完全被超越软件的想法所吸引。......该代码具有无限的可塑性。这份遗产价值无穷。你可以改变任何东西，任何软件，任何代码都可以重写。……如果软件很难改变，那是你的错。你是一个糟糕的程序员，你只需要学习变得更好。
不过，在他所谓的“七年”之后，他们陷入了困境——这与技术债务无关。
金手铐
他们首先注意到自己的直觉缺乏热情。他们不仅没有动力开发他们的旗舰产品，而且他们自己也没有那么多地使用该产品。
他们有很多关于如何从根本上改进产品的想法，但是随着成千上万的人围绕 Basecamp 构建他们的工作流程，他们所做的每一个改变都会对很多人造成破坏。改变的障碍不是笨拙的代码库，而是他们的用户。
他们专注于让现有客户群满意，因此及时冻结产品，并阻止他们吸引新客户。这对企业来说不是一个直接的问题，但它构成了一个长期威胁。DHH 使用了试图让漏水的桶装满的比喻：
你可能会堵住所有的漏洞，你可能会修复所有的错误，你可能会升级现有客户抱怨的所有功能，这样就不会漏水——但总有一些水会漏掉。客户离开他们的工作并离开你的软件，即使他们[喜欢它]。但是你可以自欺欺人地说，“嘿，这个水桶还有一半多。那只是一个渗出的小洞，这是非常自然的。” 但是，如果你只是保持它足够长的时间，水桶最终会变空。
部分问题是您一直听到现有客户的消息，但听不到未来客户的消息：
那些在 2011 年出现在 Basecamp 主页但因为我们的想法不再足够好而选择不购买的人，您认为我们多久收到一次他们的来信？绝不。我们从广大的现有客户群那里听到，他们非常希望我们继续填补这些小漏洞。
他们开始将盈利产品视为一副金手铐：
第一件事就是确保您已经拥有的所有用户仍然满意。钱每个月都不断地进来，新的支票，新的支票，新的支票。伟大的。但是，您必须伸出双臂说：“好吧，我再也不会更改我的软件了。”
剧透警告：他们从头开始重写了 Basecamp，结果非常棒。花了大约一年的时间，新注册人数在 Basecamp 2 发布后立即翻了一番。
我认为，他们做了两件有趣的事情，使这项工作成功。
首先，他们没有尝试重建他们已经拥有的确切产品——因为他们对如何解决他们最初打算解决的问题有了新的想法。
我们真的那么傲慢地认为我们在 2003 年的想法在 2011 年仍将是最好的想法吗？我的意思是，我一直被指责为非常傲慢，但我在 2008 年那样的时候就失去了动力。
因此，他们将 Basecamp 2 作为一个全新的产品展示，但不保证它会向后兼容 Basecamp Classic。很多东西是新的，其他东西已经消失，很多东西完全不同。
这个决定给了他们一定程度的自由。自由是激励，有动力的人会完成更多的工作。
不必支持原始产品的每一个用例也为他们赢得了很多时间。例如，最初的 Basecamp 允许用户在他们自己的 FTP 服务器上托管文档。去掉那个功能——以及其他类似的功能，这可能曾经有商业意义，但现在已经没有了——使得在合理的时间内将新产品推向市场成为可能。
日落被认为是有害的
但是那些成千上万的现有用户呢？所有那些在奶酪被移动时大声抱怨的人？
这让我们想到了他们所做的第二件有趣的事情，那就是他们没有淘汰现有产品。
大卫对“日落”软件的概念进行了一段时间的讨论：
有人在某个地方想出了这个美丽的委婉说法，叫做日落。……让我们称杀戮软件为“日落”吧。......所有用户都可以坐在沙滩上，他们可以看到他们所有的数据都消失了。这将是美丽的！
唯一相信“日落”的人是那些称它为“日落”的人。没有真正经历过日落时期的用户真正回来说，“哦，那太美了。” 他们回来说：“操！我在这件事上付出了多年的努力！......现在你要让我日落？
他指出，当你强迫用户打包搬家时，就是你犯下“有史以来最糟糕的战略错误”的时候：因为你正在夺走整个经常性客户群，并让他们考虑是否要继续使用你的产品软件或完全转移到其他东西。
“Basecamp 真的是我想要的东西吗？如果无论如何我们都必须把所有的垃圾都搬过来，也许我可以把它搬到别的地方。如果我必须把它们全部装进箱子里装上卡车，我可以直接让卡车穿过城镇。这不是什么大麻烦。最大的麻烦是收拾我所有的狗屎。无论是再次去 Basecamp 还是去其他地方，这都不是什么大决定。”
David 将 Basecamp Classic 与 Leica M3 进行了比较：它自 1967 年以来就没有生产过，但 Leica 仍然致力于支持它并在其营业期间对其进行维修。（照片Dnalor 01）
相反，Basecamp 致力于“尊重他们的遗产”：他们让人们可以轻松升级，但不要求他们离开 Basecamp Classic。不仅如此，他们还承诺无限期地继续托管、支持和维护 Basecamp Classic。
更重要的是，四年后，他们又做了一遍：Basecamp 3 于 2015 年发布，从头开始重写，删除了一些功能，添加了一些功能，并且进行了很多更改。和以前一样，旧版本的用户可以轻松升级——但如果他们愿意，他们可以继续使用 Basecamp Classic 或 Basecamp 2，“直到互联网结束”。
Basecamp 3 不会落下任何东西。不是 Basecamp 的当前版本，也不是 Basecamp 的经典原始版本。这些都适合你吗？惊人的！请继续使用它们直到互联网结束！我们将确保它们快速、安全且始终可用。
但是，但是，但是不是很贵吗？那不难吗？安全性如何？遗留代码库呢？是的，那又怎样？照顾好客户——即使他们对按照我们的时间表进行升级不感兴趣——也是我们在这里所做的。
教训
就个人而言，我觉得这个模型真的很鼓舞人心。
每次重写都允许 Basecamp 重新审视设计决策并构建他们希望上次构建的产品。
对于用户来说，这是两全其美：不喜欢变化的人不会动他们的奶酪；但是遇到您产品局限性的人们开始使用新的、希望经过深思熟虑的应用程序。
必须无限期地维护产品的多个版本并不是没有代价的；但正如大卫所说：
它不是免费的。你为什么期望它是免费的？它很有价值，所以当然不是免费的。但这是值得做的。
3. Visual Studio 和 VS 代码
VS 97 -> 6.0 -> .NET -> ... -> 2015 -> 2017 -> 2019 ------ -> VS 代码 -------------- ->
钥匙： = 街头信誉
微软制作 VS Code 是为了接触在其他平台上工作的开发人员。
你必须记住，长期以来，在微软的世界里工作是一个孤注一掷的命题。如果您使用 Visual Studio，那么您就在 .NET 中工作，反之亦然。这将软件社区分裂成两个大的、几乎相互排斥的阵营——对每个人都不利。
接触酷孩子
即使在 Steve Ballmer 时代，这种情况也开始发生变化 — 请记住，当ASP.NET 团队决定不重新发明 jQuery时，这是一件多么了不起的事情！
明确吸引围墙花园外的开发人员已成为微软首席执行官萨蒂亚纳德拉的主要任务之一。
但正如 Visual Studio 副总裁 Julia Liuson 在本期 The Changelog 播客中所说：
我们没有为这一类开发人员提供任何东西——现代的、webby 的、面向 Node 的开发人员、JavaScript——我们没有什么可和你谈的。你是我们永远无法吸引到的开发者。
所以 VS Code 的动机是打破这个障碍并说“实际上，你知道吗？我们确实有一些你可以使用的东西。”
Visual Studio 在任何意义上都是重量级产品：安装可能需要半小时以上。它必须支持企业客户所依赖的各种复杂用例。因此，以 Visual Studio 本身为起点，微软试图通过添加功能来吸引其他平台是没有意义的。大概制作 Mac 或 Linux 版本的 Visual Studio 的想法是行不通的。
所以微软从头开始，没有向后兼容性的保证。
实际上，并非完全是从头开始：微软已经拥有一些重要的部分，例如浏览器内的 Monaco 编辑器。因为 VS Code 是一个 Node.js 应用程序（用 Typescript 编写并在 Electron 中运行），他们能够利用丰富的 JavaScript 生态系统。
VS Code 是开源的、轻量级的、快速的和可扩展的；而且——令人惊讶的是，对于微软的产品——它已经成为酷孩子们的首选编码环境。
VS Code 已成为 JS 潮人的首选文本编辑器。（图表来自JavaScript 现状调查，2018 年）
这两款产品仍在积极开发中，没有迹象表明微软打算淘汰 Visual Studio。
教训
与 Netscape 的经历形成鲜明对比的是，微软成功地围绕 VS Code 建立了一个活跃的开源社区。这个社区使内部开发团队的努力成倍增加。
在 GitHub 上的所有开源项目中，Visual Studio Code 的星数排名第 13 位——巧合的是，仅次于 Linux！
当然，并不是每个人都有支持完全开源其核心产品的商业模式。
但是，如果开源是您开发策略的一部分，那么可能值得比较这两个案例研究，以找出 Microsoft 的做法如此不同，从而导致该社区蓬勃发展。
另一个乘数：微软还为 VS Code 配备了可靠的可扩展性模型，因此社区已经编写了近 10,000 个扩展。
VS Code 故事的最后一个要点是，过去几年事情发生了根本性的变化，以一种比以往任何时候都更容易制作原型和创建软件的方式。
尽管人们对当今工具集的复杂性感到担忧，但事实是 JavaScript 生态系统在过去几年中已经发展成为期待已久的可重用、模块化开源代码的应许之地。在这方面，这是历史上前所未有的时期。
4. Gmail 和收件箱
Gmail -------------------------------------------- ---- -> Gmail 收件箱 ------ ↗ -- ↗ -- ↗
钥匙： = 日落
Gmail 的收件箱最初是作为 Gmail 的精简替代用户体验而引入的，“旨在专注于真正重要的事情”。它从未达到与原始 Gmail 相同的功能，并且引入了新功能，如捆绑、固定电子邮件和延后消息。
包括我在内的一些人热情地采用了 Inbox。我一直认为 Inbox 是 Gmail 最终会变成什么样子的预览，并容忍 Gmail 缺少一些细节，并期望它们最终会出现在 Inbox 上。
两个接口，一个服务
Inbox 和 Gmail 使用相同的后端。它们本质上只是同一服务的不同用户界面，您可以随意切换。这有利也有弊：如果 Inbox 缺少一项功能（例如，假期自动回复），您可以随时返回 Gmail 并在那里执行您需要的操作。但是来回切换时不可避免地会出现一些怪异现象。
不过，过了一段时间，Inbox 停止了改进，而且很明显 Google 不再在其中投入任何资源。果然，在推出四年后，谷歌宣布将淘汰Inbox。
起初我很恼火，但在使用最新版本的 Gmail 一段时间后，我发现Inbox 中我最喜欢的许多功能已移植到原始产品中：智能回复、悬停操作以及内联附件和图像。Gmail 的多个收件箱足以替代 Inbox 的捆绑包。
但并非一切都结束了：例如，打瞌睡已成为有多少人处理电子邮件的关键部分；收件箱的消亡使它们变得高高在上。
教训
Inbox 为 Gmail 团队提供了一种在不中断工作流程的情况下为绝大多数未选择切换的用户试验功能的方法。
但是，通过承诺让两个版本使用相同的后端，Gmail对自己的创新能力施加了严格的限制。
谷歌再次因关闭一项受欢迎的服务而受到很多批评。当然，谷歌一直在停产 产品 ，所以我们期望什么。
在这种情况下，Google 围绕 Inbox 的原始消息让我们相信我们可以早日看到 Gmail 的未来。正如 DHH 所说，这不是美丽的日落；对于许多人来说，不得不回到旧产品并失去 Inbox 的创新工作流程是一件很糟糕的事情。
我认为，如果 Gmail 在关闭之前一直在功能上与 Inbox 平起平坐，那么人们的不快就会少一些。
5.FogBugz 和 Trello
FogBugz ------------------------------------ 特雷洛 -------------------------- ->
关键： = 悲伤的衰落 = 钱钱钱
FogBugz 是一个特别有趣的案例，因为它是 Joel Spolsky 的产品：它让我们看到永不重写原则如何在现实世界的产品中发挥作用。
在 Jira 出现之前，在 GitHub Issues 出现之前，有一个基于 Web 的错误跟踪产品，叫做 FogBugz。它于 2000 年发布，是 Fog Creek Software 的第一款产品，这家公司是 Joel 最近与 Michael Pryor 共同创立的；十多年来，它一直是他们的旗舰产品。他们最初只将其作为安装在您自己的服务器上的收缩包装软件出售，但后来推出了托管订阅版本。
它变得非常流行，尤其是在那些像我一样关注 Joel 的博客并将他的建议牢记在心的开发人员中。我公司用了很多年；它在当时是一个伟大的产品。
FogBugz 最初是用运行在 Windows 服务器上的经典 ASP 编写的。当 ASP.NET 出来时，Joel 解释了为什么他不急于升级.
为了让人们能够在 Linux 服务器上安装 FogBugz，一名实习生编写了一个名为 Thistle 的编译器，用于将经典的 ASP 转换为 PHP。到 2006 年，Thistle 已经发展成为一种名为 Wasabi 的私有本土语言，可以编译为 ASP、PHP 和客户端 JavaScript。
芥末的奇怪故事
现在开发一种内部专有的编程语言和编译器是——我们只能说这是一个古怪的选择。所以请容忍我绕道而行。
有一次，乔尔在一篇博文末尾的一段随手描述了芥末。显然有些人认为他不是认真的，他澄清说他是。这导致博主 Jeff Atwood 的脑袋爆炸了：
编写自己的语言绝对是天方夜谭。这是一个有毒的决定，与 Joel 之前关于软件开发的出色而明智的建议完全不一致，以至于人们真的认为他是在开玩笑。
Joel坚持认为这一切都具有商业意义：如果您从头开始，当然不会发明自己的语言。但是，如果你一路审视每一个决定，考虑当时的技术背景和他们当时拥有的代码库，你就会看到你最终会怎样。
前 Fog Creek 工程师 Ted Unangst 在一篇题为“技术债务和顺风”的深思熟虑的文章中反思芥末，将这个过程比作没有地图的旅行：
假设您在佐治亚州萨凡纳，想去英国伦敦。你没有地图，只有模糊的方向感。......你不能直线前进，至少不能不造船，因为路上有一片海洋。但是有一个漂亮的海滩通往东北方向，就是你想去的方向。就行了。时间流逝。您注意到您并没有直接前往目的地，但每走一步，您就离目的地越来越近。
在波士顿或新斯科舍附近的某个地方，您终于停下来思考您的选择。也许这不是去伦敦的路。在花生画廊的高处，您可以听到咯咯声。“哈哈哈，看看这些弱智。分不清英格兰和新英格兰。给这些傻瓜一张地图。” 但仅此而已；你没有地图。地图是由几乎从定义上说不知道自己要去哪里的人制作的。
无论如何，正如 Fog Creek 的另一位前开发人员 Jacob Krall解释的那样，这一决定以今天的开发人员速度换取明天的可维护性——技术债务的定义——到 2010 年，这笔债务的账单开始到期。
我们没有开源 [Wasabi]，因此这意味着我们必须以牺牲主要创收产品为代价进行任何投资。......这是一个巨大的依赖关系，需要一名全职开发人员——对于我们这种规模的公司来说并不便宜。它偶尔会吐出一段对人类来说完全合理的代码。编译很慢。Visual Studio 无法轻松编辑调试器或将调试器附加到 FogBugz。......所有新员工都有很长一段时间学习芥末，无论他们以前的经验如何。……更重要的是，我们并不是生活在真空中。编程语言当然在 Fog Creek 之外得到改进。......开发人员开始觉得他们的绝妙想法受到了我们小小的 Wasabi 宇宙的限制。
一个拐点
在这一点上，十年过去了，FogBugz 是一个成熟稳定的产品。Joel 与 Jeff Atwood 一起创建了 Stack Overflow 作为副项目（大概那时他爆炸的脑袋已经有时间痊愈了）。
FogBugz 并没有让世界着火，它正在显示它的年龄。虽然错误跟踪器市场仍然分散，但 Atlassian 的 Jira——在 FogBugz 之后几年问世——已成为默认选择，尤其是对于大型企业用户而言。
我对 Fog Creek 历史上的这个特殊转折点有点着迷。和 Basecamp 一样，他们有一个盈利的、成熟的产品。它不再性感，工作起来可能也不是很令人兴奋。无论好坏，它都体现了多年的技术变革和关于如何解决特定问题空间的不断发展的想法。
当然，一种回应是像 Basecamp 所做的那样：利用 Fog Creek 在错误跟踪方面学到的所有知识，并从头开始重新发明 FogBugz。
我猜这个想法并没有走得太远——“你永远不应该做的事情”、“最严重的战略错误”等等。
我最近看到一篇 2009 年的文章，当时 Joel 正在为 Inc. Magazine 撰写每月专栏。本专栏标题为“缓慢增长是否等于缓慢死亡？”，与他一贯自信的夸夸其谈的语气截然不同：它是内省的、试探性的、怀疑的。他对 Atlassian 的快速增长感到担忧——想知道最终是否只有一种产品在错误跟踪市场中占有一席之地。
我不得不怀疑。我们的市场上确实有一个强大的竞争对手，它的增长速度似乎比我们快得多。该公司正在与大型企业客户达成大笔交易。……与此同时，我们的产品要好得多，而且我们是一家经营良好的公司，但这似乎并不重要。为什么？
所以他决定做两件事。首先，将所有功能添加到 FogBugz 中：
这就是开发团队 2010 年的使命：消除客户可能会购买我们竞争对手的垃圾产品的任何可能原因，仅仅因为有一些他们告诉自己绝对不能没有的极小功能。坦率地说，我认为这不会很难。
二是打造企业销售队伍。乔尔承认这是他不擅长的事情，并且觉得很反感。
我不知道这两个计划的结果如何。Joel 上一次在他的博客上提到 FogBugz 是在几个月后敷衍了事地发布了次要版本。
新希望
发生的事情是这样的：
在 Fog Creek Software 成立十周年之际，我开始思考，如果我们想让我们的员工在下一个十年里保持兴奋和积极性，我们就需要做一些新的事情。
因此，他们分成两个小组，每个小组都致力于提出新产品创意并制作原型。
获胜想法的灵感来自看板——一种物理工具，通常用于软件开发，通常涉及分布在白板上各栏的便利贴。
Joel 将其作为一种工具，用于管理比 FogBugz 允许的更高级别的工作：
老实说，尽管市面上有那么多花哨的“项目管理”软件，但我从来没有找到一种方法来跟踪谁应该从事什么工作。......作为两家公司的创始人，走在走廊上看到几十个人坐在电脑前得到报酬......我不知道他们是否在做正确的事情，或者他们认为重要的事情但是，尽管如此，这实际上并不重要。
在构建 Trello 的过程中，Fog Creek 的开发人员有机会使用现代技术进行改变：
我们使用尖端技术。通常，这意味着我们会割伤手指。我们的开发人员在 MongoDB、WebSockets、CoffeeScript 和 Node.js 上流血。但至少他们玩得很开心。在当今紧张的就业市场中，优秀的程序员对他们将要从事的工作有很大的影响力。如果您能为他们提供令人兴奋的产品……他们会从中获得乐趣，并且会热爱自己的工作。
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。
在首席执行官Anil Dash 的领导下，Fog Creek 成为一家单一产品公司，并更名为 Glitch。
教训
我对这一切有很多感受。
打造一个舒适的工作场所是我们的首要目标。我们有私人办公室，乘坐头等舱，每周工作 40 小时，并为人们提供午餐、Aeron 椅子和顶级电脑。我们与全世界分享了我们独创的公式：出色的工作条件 → 出色的程序员 → 出色的软件 → 利润！
理解整个故事的关键在于，Fog Creek 从来都不是关于错误跟踪，而是关于赋予程序员权力——从他们自己开始：
考虑到这个“公式”，也许我们可以拼凑出一个连贯且鼓舞人心的故事：Fog Creek 围绕开发人员的幸福建立了业务。这反映在公司的产品及其内部“操作系统”中。它的第一个产品是错误跟踪器，为推出以更广泛适用的方式解决类似问题的新产品奠定了基础。
我认为这确实说明了 Trello 的起源故事，Joel 讲述它的方式，与其说是 Joel 寻找新的商业机会，不如说是 Joel 寻找一种让Fog Creek 的开发人员开心和参与的方法。创造一个价值 50 亿美元的产品，这只是一个令人愉快的意外结果。
不过，我不禁为 FogBugz 的结局感到有点难过。我不认为在 Fog Creek 产品的最后几天会有很多开发人员的快乐。
显然，所有相关人员都有更大的鱼要炸：Stack Overflow、Trello 和 Glitch 各自都比 FogBugz 更有用和更有价值；任何特定的人都只能用他们的时间做这么多。因此，我不会特别嫉妒任何人对 FogBugz 失去兴趣，因为它有两个十年的代码库和竞争激烈的利基市场。至少它的忠实用户找到了一个好归宿，没有得到“日落”待遇！
但我内心深处的情感部分希望有一种更好的方式来“尊重那些年来创造和使用它的所有人的遗产”。
6. FreshBooks 和 BillSpring
FreshBooks ------------------------------------------------ ->
️BillSpring ------- ↗
关键：️♀️ = 卧底行动
这已经变成了一篇比我想象的要长得多的文章，但我不能把这个故事漏掉。坚持我，它有一个很大的转折。
如果你以前听过这个，请阻止我
2000 年代初期，Mike McDerment拥有一家小型设计机构。他正在使用 Word 和 Excel 来制作发票，因为他认为会计软件对于他需要的东西来说太复杂了。
这个系统本来就足够好，但后来却不是：迈克是一名设计师，而不是程序员，但他和两位联合创始人设法拼凑出一个足够好的工具，只有少数人每月支付 10 美元才能使用它。这家公司花了将近四年的时间才赚到足够的钱让他搬出父母的地下室。
有一天，当我不小心节省了一张重要的客户发票时，我达到了临界点——我有点生气了。我知道必须有更好的方法，所以我在接下来的两周里编写了代码，这将成为现在 FreshBooks 的基础。
到产品 10 周年纪念日（这听起来很熟悉吗？）FreshBooks 盈利稳定，拥有超过 1000 万用户和 300 名员工。
只有一个问题：当他们设法聘请“真正的”程序员时，他们已经有一百万行“创始人代码”。一位外部分析师审查了他们的代码库并得出结论：
“好消息是你已经解决了最难的问题。您已经了解如何建立业务，并且拥有人们喜爱的产品。**坏消息是你们这些家伙对技术很讨厌。**”
不过，更重要的是，他们有了现有产品无法提供的新想法：
我们十多年前创办了这家公司；世界已经改变，我们在构建产品和服务为自己工作的人方面学到了很多东西。虽然自雇专业人士及其团队是劳动力中的一个庞大且不断增长的部分……为了让 FreshBooks 能够跟上步伐并在五年内为该群体提供良好服务，我们知道我们需要采取行动。
McDerment吸收了关于从头开始的传统智慧：
对于软件公司来说，没有比重写更大的风险了。您甚至可能无法完成该项目。这将花费比你想象的更长的时间。它会花费更多。当您这样做时，客户可能不会喜欢它。并且不能保证通过构建新平台它会成为更好的产品。软件中的第一条规则是您不要重新平台化您的软件。
因此，他们进行了几次尝试来清理混乱而不是重新开始；但发现不可能“在移动的车辆上更换轮胎”。
接下来发生的事情可能会让你大吃一惊
McDerment 最终想到的想法是秘密创建 FreshBooks 的“竞争对手”。
他在特拉华州成立了一家名为 BillSpring 的全新公司。新公司有自己的 URL 以及自己的品牌和徽标。为了避免将这两家公司联系起来，他让一位外部律师起草了新的服务条款。
开发团队采用了Jeff Gothelf和Josh Seiden合着的《精益用户体验：使用敏捷团队设计伟大的产品》作为他们的指南，并实施了敏捷实践，例如 scrum 团队和每周迭代与真实客户的回顾会议。McDerment 告诉他们把自己想象成一家初创公司，而自己则是他们的风险投资家：
“你有四个半月的时间。如果那时你在市场上，我们会给你更多的钱。否则，我们就出去了。”
第一年结束时，他们开始向 BillSpring 客户收费。有一次，新产品以一种意想不到的方式得到验证：
该团队设法在截止日期前几天提出了 MVP。他们购买了 Google AdWords 以将流量引导至新网站。他们提供第一年的免费帐户。不久他们就有了实际用户，他们开始快速迭代以完善产品。
“有人打电话给我们取消 FreshBooks，告诉我们他们要去这家新公司，”McDerment 说。“那是美好的一天。”
不久之后，他们揭开了秘密的面纱：他们让 BillSpring 客户知道该产品现在是 FreshBooks，并让现有的 FreshBooks 客户知道新版本即将推出。
渐渐地，“FreshBooks Classic”客户被邀请尝试新的升级——但他们没有必要，如果他们愿意，他们总是可以迁移回更熟悉的版本。
教训
FreshBooks 的秘密重写并不便宜：McDerment 估计他们在该项目上花费了 700 万美元。经过十多年的自力更生，他们刚刚筹集到 3000 万美元的风险投资；所以他们有现金。不是每个人都有那么多钱可以花。
福布斯 估计，FreshBooks 在 2013 年的收入为 2000 万美元。2017 年，升级完成后，他们赚了 5000 万美元。他们没有说增长有多少来自新产品，但重新开始似乎并没有减缓公司的增长。
McDerment 报告说他们现在能够更快速、更轻松地添加功能。更重要的是，他们正以一种能够捕捉他们最佳创意的产品面向未来。
不过，除了他们既定的目标之外，他们还发现这种体验改变了公司文化——以一种好的方式。他们假装是一家初创公司的时间让他们表现得更像一家初创公司。他们试验的“精益”实践传播到整个工程团队。客户密切参与新功能开发。
FreshBooks 竭尽全力使自己免受重写的潜在不利影响：通过在一次性品牌下进行创新，开发人员可以自由地彻底重新考虑事情，并承担更大的风险。那样的话，最坏的情况就是他们会走到另一个死胡同；至少他们不会在这个过程中损害他们现有的品牌。
这一切都感觉有点极端，也许没有必要像他们那样竭尽全力。但它提醒人们，赌注有多么严重。
目前的一些想法
围绕重写软件的传统观点是，您通常应该避免重写软件，而是进行渐进式改进——除非由于某种原因确实不可能这样做。
就目前而言，我同意这一点。
不过，此建议假定目标是最终获得原始产品以及一些新功能。
但是如果你想删除功能怎么办？或者，如果您想以完全不同的方式解决某些用例怎么办？如果您对产品的体验为您提供了一种全新方法的想法怎么办？
我从这些故事中得出的结论是：一旦你充分了解到你的产品的当前版本与你能想象到的该产品的最佳版本之间存在一定的差距，那么正确的方法就是不要用新的软件替换你的软件版本，而是在它旁边构建一些新的东西——不要扔掉你拥有的东西。
因此，如果您正在考虑是否应该重写，您应该看看您的产品并问问自己：我是否应该创建自己的竞争对手？如果我的产品是 FogBugz，那么我的 Trello 是什么？如果是 Visual Studio，我的 VS Code 会是什么样子？
如果您并排重新阅读Spolsky在 Netscape 上的帖子和DHH在 Basecamp 上的帖子，您会发现他们同意一件事：您已经创造的东西具有价值。
好消息是，您不必为了创新而放弃该价值。
