完美的代码无法拯救你的公司

软件工程是一个有技术门槛的行业。好的软件工程师总是事半功倍，他们可以完成别人甚至都不知道如何开始的工作。但是为什么几乎找不到那种公司，是由技术大牛带着一群人，开开心心地写着完美的代码呢？这是不是一场阴谋，是那些不懂技术的管理和市场人员，想要压制聪明的技术人员？

Software engineering clearly takes skill. A good software engineer is a force multiplier, and can accomplish tasks that other engineers wouldn’t even know how to start. So why are there little-to-no tech companies with perfect codebases that are a delight to work in led by rock star engineers? Is there a conspiracy by the dastardly managers, suits, and business people to keep the heroic and smart engineers down?

显然没有这样的阴谋。但为什么当我们想要重构一段糟糕的代码、想要换一种更加方便的编程语言，又或者想要使用显著提升开发体验的服务时，会发现说服管理层是如此之难呢？为什么管理层似乎总是鼓励糟糕的代码和技术债呢？

Obviously there’s no such conspiracy. But then, why is it so hard to convince management to rewrite a terrible codebase? Or rewrite in a different language that’s much nicer to work with? Or use this new service that improves DevEx significantly? Why does management always seem to encourage bad code and tech debt?

上面的种种问题，在于如今对于大多数公司而言，并不是由代码质量来决定其生死。当糟糕的代码仍能带来数十亿美元的收入，市场就不会激励巧妙的设计，而是激励速度和执行力。

The answer to all those questions is that these days, most companies simply aren’t living or dying by the quality of their codebase. Horrible codebases account for billions of dollars in revenue. The market doesn’t incentivize clever engineering, it incentivizes speed and execution.

烹饪我认为是一门技艺，一个好厨师是一位工匠——而不是一位艺术家。这并没有什么错：欧洲那些宏伟的大教堂是由工匠建造的——尽管不是由他们设计的。以专业的方式实践你的技艺是高尚的、光荣的且令人满足的。而且通常情况下，我任何时候都会选择一个以其专业精神为傲的职业雇佣兵，而不是一个艺术家。

Kitchen Confidential - Anthony Bourdain

Cooking is a craft, I like to think, and a good cook is a craftsman-not an artist. There’s nothing wrong with that: the great cathedrals of Europe were built by craftsmen-though not designed by them. Practicing your craft in expert fashion is noble, honorable and satisfying. And I’ll generally take a stand-up mercenary who takes pride in his professionalism over an artist any day.

• Kitchen Confidential - Anthony Bourdain

软件市场是独特的，因为与其他行业相比，软件择优更换相对容易。公司能以相对较少的投资，服务几乎无限的客户。想象一下，如果所有的披萨店都能随时且及时配送到世界上任何地方，那还会有人愿意接受难吃的披萨吗？这就是软件行业的现实，它的独特性使其变得利润丰厚：赢家迅速占据主导地位，以至于同一个市场中不可能存在两个竞争者。

The software market is unique because switching to the better option is relatively easy compared to other industries and companies can service near infinite customers with relatively little investment. Imagine if all pizza places can immediately deliver to anywhere in the world, instantly, at every hour of the day. Would anyone ever settle for bad pizza? This is the reality for software, and it’s uniqueness is what makes it so lucrative: winners quickly dominate such that it’s impossible for two competitors to exist in the same market.

但似乎很多情况下可以多个竞争者共存呀？比如 Slack、Teams 和 Discord。实际上，看似相似的竞争者之所以能够共存，要么是因为它们服务于不同的细分市场，要么是因为风险投资和长期合同支撑起了那些失败者。就比如上面提到的 Discord，它服务于一个明显不同的细分市场，而 Slack 则在微软开始赢得企业客户后就被卖给了 Salesforce。今天无论你写出了一个多么完美的 Slack 仿制品，如果它没法服务于一个区别于竞品的细分市场，那么它大概率会无人问津。

But isn’t there a lot of cases where multiple competitors coexist? What about Slack, Teams, and Discord? In reality, seemingly similar competitors only coexist either because they serve different market niches, or a loser is propped up by VC funding and long business contracts. In the given example, Discord serves a distinctly separate niche, while Slack sold to Salesforce after Microsoft started winning the enterprise clients. Today, it wouldn’t matter how well you code a Slack clone, if it doesn’t appeal to a different market niche it likely won’t go anywhere.

这些有利可图的细分市场在哪里？在被成功证明之前，没有人知道。所以大家都在通过迭代测试市场。风险投资公司通过广撒网来寻求超额回报。大型科技公司不断资助与业务无关的非盈利项目以寻求增长，以保住自身的估值。独立开发者承诺在 12 个月内完成 12 个项目。大家都是找一群猴子来涂鸦，然后期待其中某一只可以写出《双城记》，因为这就是在这个市场上取得成功的方式。

Where are these profitable market niches? Until the market is proven through success, nobody knows where these profitable market niches do and don’t exist. That’s why everybody is testing the market iteratively. VCs throw money at a lot of different companies in search of outsized returns. Large tech companies constantly fund unprofitable projects unrelated to their money-maker in search of growth to justify their valuation. Indie hackers commit to 12 projects in 12 months. Everybody is basically hiring monkeys until they get A Tale of Two Cities, because that’s how you succeed in this market.

我们在 Snapchat 出现之前就有类似它的东西了。但随后，Snapchat 推出了“故事”功能，当他们推出这个功能时，我就想：“哦，该死，这就像是我们正在构建的东西，但要好得多，而且他们还在我们之前发布了。所以，就好像，我们在 Snapchat 出现之前就是 Snapchat，但我们在 Snapchat 出现之后也还是 Snapchat（笑）。就像是在说：“Snapchat 用户们，我知道你们喜欢你们的产品，我也知道它很棒，但我们有比它更差的东西给你们，再给我们几个月时间。”

Casey Neistat, talking about BEME on Steve-O’s Wild Ride (YouTube)

We were Snapchat before Snapchat. But then, Snapchat launched Stories, and when they launched Stories I was like, “Oh shit, that’s like what we’re building but way better, and they released it before us. So like, we were Snapchat before Snapchat, but we were also Snapchat after Snapchat [Laughs]. It’s like, “Look Snapchat users, I know you love your product and I know it’s great, but we got something worse for you, just give us a few more months.”

• Casey Neistat, talking about BEME on Steve-O’s Wild Ride (YouTube)

基于目前的市场环境，重构代码能获得多少投资回报？确实，我们应该坚持好好写代码，因为你的代码往往比想象中要运行得更久。但是又有多少精心编写的代码，因为它所构建的产品并不满足市场需求，最终却被闲置了呢？工程师的价值并不在于写出完美的代码，而在于能够帮助他们的团队在市场上击败竞争对手。

Given these market conditions, what kind of return-on-investment do you get by rewriting your codebase? We should always write good code, because sometimes your code lives longer than you think. But how many lines of perfectly crafted code is now sitting unused because the product it built never served a market niche? More important than having the perfect codebase, the most valuable thing an engineer can do is to give their team more tries at beating the competitors to the market.

写出高质量的软件需要时间，为了更快交付我们应该放弃代码质量吗？实际上交付速度与交付质量并不冲突。好的软件工程师一直努力编写可维护（或者说“更容易修改”）的代码，因为后续不可避免地需要修改这些代码，到那时便可以节省时间。无论是在最初编写还是在后续迭代的时候，高质量代码的价值都在于节省时间。

But doesn’t good software take time? To build faster, should we forsake code quality? Actually, building faster has never been mutually exclusive with quality. Good software engineers have always strived to write maintainable code (or, “easier to change”). Why? So we can save time when we inevitably change it later. The value of quality code has always been about saving time, both when first writing and also down the line when iterating.

要求工程师更快地交付并不意味着展示技能的机会更少，实际上机会更多。优秀的工程师知道如何以简单的方式编写代码和设计架构，并且遵循 YAGNI（You Aren’t Gonna Need It）原则。他们还知道如何在保持产品正常运作的前提下处理技术债。一个优秀的工程师会为你的公司带来巨大利益，要求他们接受市场现实不会改变这一点。

Engineers asked to build faster doesn’t mean less opportunities to showcase skill, it actually results in more. Good engineers know to code and architect in a simple manner and embracing YAGNI. They also know how to manage tech debt without completely stopping the world to eliminate it. A good engineer will still be a huge benefit to your company, and asking them to embrace market realities does not change that.

我所说的这些都不是秘密。Meta 在 2014 年将他们的座右铭从 “move fast and break things” 改成了 “move fast with stable infrastructure”。如今开发工具越来越健全，每个人都可以 “move fast with stable infrastructure”。1986 年 Fred Brooks 在《没有银弹》中指出市场在减少“意外复杂性”以来，银弹一直没有被找到，但你的竞争对手不需要通过银弹来占领市场，他们只需要比你快就行。

But actually, none of this is a secret at all. In 2014 Meta famously changed their motto from “move fast and break things” to “move fast with stable infrastructure.” These days, with all the different dev tools available, everybody can move fast with stable infra. It’s been like this since 1986, when Fred Brook in “No Silver Bullet” identified how the market has been a force in reducing “accidental complexity.” The 10x silver bullet still hasn’t been found, but your competitors don’t need a silver bullet to conquer your market, they just need to get there faster than you.