The Importance of Leverage 杠杆的重要性
Having spent over a decade building tech startups, I've come across my fair share of tech debt: The gnarly Ember.js code no one wants to touch, the bespoke cloud infrastructure maintained entirely by hand, or the solitary Elixir service left behind by a long-gone former teammate. 在建立科技初创企业的十多年里，我遇到了很多技术债务：那些令人头疼的 Ember.js 代码，没有人愿意碰的定制云基础设施，或者被离职的前队友留下的孤立的 Elixir 服务。
While these may be painful today, at one point in the past they were likely important accelerants that pushed the product forward in a meaningful way. In fact, tech debt is arguably a necessary evil–if a growing company isn't taking on some measure of leverage, then it's likely not shipping as fast as it should be. However, as a company begins to see traction, there will come an inflection point where it becomes important to start prioritizing tech debt. 尽管这些可能在今天是痛苦的，但在过去的某个时刻，它们很可能是推动产品有意义发展的重要催化剂。事实上，技术债务可以说是一种必要的恶魔 - 如果一个不断发展的公司没有承担一定程度的杠杆，那么它很可能无法以应有的速度交付产品。然而，当一个公司开始看到进展时，就会出现一个转折点，开始重视技术债务的优先级。
Usually this time will come as your business starts to scale and earlier decisions made for the sake of time start to become bottlenecks to new work. But then the question becomes, how do we prioritize paying down some of the debt we've accrued when it's competing with our bandwidth to build new features? 通常，当您的业务开始扩大规模时，之前为了节省时间而做出的决策开始成为新工作的瓶颈。但问题是，当我们需要同时处理偿还债务和开发新功能时，我们应该如何确定优先顺序呢？
Surveying the Debt 债务调查
First we want to draft a map of the landscape. Our goal here is to understand the system and how its individual components relate to one another. This needn't be overly detailed, but should provide enough specifics that we can start to examine pieces of it in terms of how components support our product workflow. As an example, if we can answer the question, "Is this a bottleneck?" then we're on the right track 首先，我们希望绘制一张景观图。我们的目标是了解系统以及其各个组成部分之间的关系。这不需要过于详细，但应提供足够的具体信息，以便我们可以开始根据组件如何支持我们的产品工作流程来检查其中的部分。举个例子，如果我们能回答问题 「这是一个瓶颈吗？」 那么我们就在正确的轨道上。
Some parts of this map may require extra attention in order to understand what parts of a specific component are causing us issue. For instance, is the data model scaling with our system or is the database technology itself the problem? 2 Examine pain points and understand not just the symptom but the underlying cause: We chose a naive data model which doesn't work at scale. 这张地图的某些部分可能需要额外关注，以了解特定组件的哪些部分导致了问题。例如，数据模型是否与我们的系统一起扩展，还是数据库技术本身存在问题？ 检查痛点，并不仅了解症状，还要了解潜在原因：我们选择了一个不适用于规模化的天真数据模型。
It's often helpful to structure this an exercise involving folks from across the wider set of teams. Ask a few representatives from each team to document various pain points and toil , especially things that are thematic or come up repeatedly. Collate this into a survey of the landscape of debt. 3 通常，将这视为一项涉及更广泛团队成员的练习会很有帮助。请从每个团队选出几位代表，记录各种痛点和繁琐工作，特别是那些主题性的或反复出现的问题。将这些整理成一份债务概况的调查报告。
Interest Rates 利率
Once we have an idea of the landscape and where within it we're experiencing pain it's time to conduct the next exercise. Enumerate each piece of debt. Perhaps you identify a fragile relationship between two services--write this down. Go through your holistic system and document each deficiency. The goal here is not to ascribe importance just yet and instead to be comprehensive. 一旦我们对景观有了一个概念，并确定了我们在其中哪里感受到痛苦，就是时候进行下一个练习了。列举出每一笔债务。也许你会发现两个服务之间存在脆弱的关系-把它写下来。检查你的整体系统，并记录下每一个缺陷。这里的目标不是立即给予重要性，而是全面地进行记录。
Now with a complete list of your tech debt as it stands go through each and answer the following questions: 现在，拿着你的技术债务完整清单，逐个回答以下问题：
-
If we choose to do nothing, will this issue become worse, remain the same, or improve? 如果我们选择不采取任何行动，这个问题会变得更糟、保持不变还是改善？
- If it'll become worse, how quickly will it degrade? 如果情况变得更糟，它会以多快的速度恶化？
- If it remains the same, how much disruption is it causing today? 如果保持不变，它今天会造成多大的干扰？
- If it'll improve, at what point will it improve to the degree it's no longer an obstruction? 如果它会改善，那么在什么时候它会改善到不再成为障碍的程度？
Assuming we decide to do nothing, then how much worse do things become? This is effectively our "interest rate" on tech debt. 假设我们决定什么都不做，那么情况会变得更糟到什么程度？这实际上就是我们对技术债务的 「利率」。
-
Is this part of the system active or dormant–are we building new features on it today or is it in maintenance mode? 这个系统的这部分是活跃的还是休眠的？我们今天是在这上面开发新功能还是维护模式？
- If it's dormant, how much time is spent on maintenance each engineering cycle? 如果它处于休眠状态，每个工程周期需要花费多少时间进行维护？
- If it's active, take note of that: you're building on a foundation that may not be stable. 如果它是活跃的，请注意：你正在建立在一个可能不稳定的基础上。
If the debt isn't part of an active area of development, then we want to understand how it's impacting development velocity. If it is, then we might be building on a rocky foundation. 如果债务不是一个活跃的发展领域的一部分，那么我们想要了解它对发展速度的影响。如果是的话，那么我们可能是在不稳定的基础上建设。
Answering these questions helps us form a rubric for grading technical debt and can then be used as a key input to prioritization alongside other work, like net-new features. 回答这些问题有助于我们制定评估技术债务的评分标准，并可作为与其他工作（如全新功能）一起进行优先级排序的重要参考。
There's no one-size-fits all here, so you'll have to decide exactly how you want to weight these criteria. However as a high-level guide, you will generally want to prioritize things that are becoming worse and which you're actively building on more aggressively. These items tend to be like high interest rates on a credit card. Whereas items that aren't degrading quickly and aren't part of the actively developed system are a more healthful form of debt. 4 For things somewhere in between, these will require more careful balancing relevant to your precise circumstances as a company. 这里没有一种适合所有情况的解决方案，所以您需要决定如何准确地权衡这些标准。然而，作为一个高层次的指南，您通常会优先考虑那些正在恶化并且您正在更积极地建设的事物。这些项目往往就像信用卡上的高利率。而那些不会迅速恶化且不是积极开发系统的一部分的项目则是一种更健康的债务形式。对于介于两者之间的事物，您需要更仔细地权衡，以符合您公司的具体情况。
When things are rapidly becoming worse and they involve active areas of development we can expect challenges. 当事情迅速变得更糟，并且涉及到活跃的发展领域时，我们可以预料到会面临挑战。
Another surprising thing you may find in conducting this exercise is that there are even a few items that are essentially self healing. These almost certainly don't require attention with the caveat that it's still important to understand how they impact product development velocity. 5 The benefit of identifying such things is that you can know to deprioritize these things in favor of the more costly items above. 在进行这个练习时，你可能会发现另一个令人惊讶的事情是，甚至有一些项目本质上是自我修复的。几乎可以肯定地说，这些项目不需要特别关注，但重要的是要理解它们对产品开发速度的影响。识别出这些项目的好处是，你可以知道要优先考虑那些更昂贵的项目，而将这些项目放在次要位置。
Staying Solvent 保持健康的财务状况
It's important to point out that leverage is a powerful tool. Technical debt is a kind of leverage and most startups will want it if not need it. So the goal of this framework is to provide a more structured view into that debt such that we can identify "good" and "bad" debt and decide how to proceed in addressing it. 需要指出的是，杠杆是一种强大的工具。技术债务是一种杠杆，大多数初创公司都希望拥有它，如果不是必须的话。因此，这个框架的目标是提供一个更有结构的视角来看待这种债务，以便我们可以识别出"好"和"坏"的债务，并决定如何解决它。
While there's no universally correct answer, we'll generally want to prioritize the high interest rate items and can continue to leverage lower interest rate items so long as they don't impede us too much. 虽然没有普遍正确的答案，但通常我们会优先考虑高利率的项目，并且只要它们不会对我们造成太大的阻碍，我们可以继续利用低利率的项目。
In the end the key thing here is to use frameworks like this to remain solvent in terms of our code base and product workflow. With tools like this, we can avoid bankruptcy (literally and figuratively). 最重要的是要利用这样的框架来保持我们的代码库和产品工作流的健康。有了这样的工具，我们可以避免破产（无论是字面上还是比喻上）。
Footnotes 脚注
- Sooner or later your rate of building new features will slow to crawl, buckling under the weight of all the short cuts and quick fixes that came before. ↩ 迟早你的新功能开发速度会变得非常缓慢，因为之前的所有捷径和快速修复措施的负担变得沉重。↩
- It's probably not the database. ↩ 可能不是数据库的问题。↩
- You might put this together as a document which can be referenced later. Having an artifact like this is important because it can serve as input to future iterations of this exercise. ↩ 你可以将这些内容整理成一个文件，以便以后可以参考。拥有这样的文档很重要，因为它可以作为未来练习的输入。↩
- Jettison this debt last, unless there are other compelling reasons to prioritize it. Healthful debt is usually the lowest priority. ↩ 除非有其他紧迫的原因需要优先考虑，否则最后再摆脱这笔债务。有益的债务通常是最低优先级。↩
- It's unlikely to be the case, but even something that improves over time can do so at a velocity that artificially holds back product development–in this instance it may merit a closer look. ↩ 虽然可能性不大，但即使是随着时间推移而改进的东西，也可能以一种人为地拖慢产品开发的速度进行改进 - 在这种情况下，可能值得更加仔细地观察。
