managing-tech-debt

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Managing Tech Debt

管理技术债务

Help the user manage technical debt strategically using insights from 18 product leaders.

借助18位产品负责人的见解，帮助用户战略性地管理技术债务。

How to Help

如何提供帮助

When the user asks for help with tech debt:

Understand the situation - Ask about the nature of the debt (legacy systems, code quality, architectural limitations), how it's manifesting (slow velocity, incidents, inability to ship), and the business context
Diagnose the urgency - Determine if this is blocking critical business needs or a slower-burning issue
Choose the right approach - Help them decide between incremental improvement, targeted refactoring, or (rarely) a full rewrite
Build the business case - Help quantify the cost of the debt and communicate value to stakeholders

当用户寻求技术债务相关帮助时：

了解具体情况 - 询问债务的性质（遗留系统、代码质量、架构局限性）、表现形式（交付速度缓慢、故障频发、无法发布新功能）以及业务背景
判断紧急程度 - 确定该债务是否阻碍了关键业务需求，还是属于缓慢发酵的问题
选择合适方案 - 帮助用户决定采用增量改进、针对性重构，或是（极少数情况）完全重写
构建业务案例 - 帮助量化债务成本，并向利益相关方传达债务削减的价值

Core Principles

核心原则

Rewrites almost never work

重写几乎从来都行不通

Camille Fournier: "Engineers notoriously, notoriously, notoriously, massively underestimate the migration time for old system to new system. By the way, you still have to support the old system while you're working on the new system." Full rewrites are traps. Prefer incremental evolution - uplift specific components rather than starting from scratch.

Camille Fournier：“工程师出了名地、严重地低估旧系统迁移到新系统的时间。而且，在开发新系统的同时，你还得维护旧系统。”完全重写是陷阱。优先选择增量演进——升级特定组件，而非从零开始。

Tech debt is product debt

技术债务就是产品债务

Ebi Atawodi: "Infrastructure is the product. Period. I cannot build a skyscraper on a shaky foundation. So it is your problem too - it's not for the engineer to be barging on the door." Technical debt should be owned by PMs as "product debt," not treated as an engineering-only concern. Include it in your Top 10 Problems list.

Ebi Atawodi：“基础设施就是产品，就这么简单。我不可能在不稳固的地基上建摩天大楼。所以这也是你的问题——不该只由工程师来敲门反映。”技术债务应被产品经理视为“产品债务”，而非仅由工程师负责的事项。将其纳入你的“十大问题”清单。

Startups should strategically take on debt

初创公司应战略性地承担债务

Gaurav Misra: "As a startup your job is to take on technical debt because that is how you operate faster than a bigger company." Debt is leverage - evaluate if a problem can be solved by a future hire rather than today. But monitor the "interest" - if maintenance takes 80-90% of time, you've run out of runway.

Gaurav Misra：“作为初创公司，你的工作就是承担技术债务，因为这能让你比大公司运转得更快。”债务是一种杠杆——评估问题是否可以留给未来的员工解决，而非现在就处理。但要监控“利息”——如果维护工作占据了80-90%的时间，你的发展空间就耗尽了。

Delete code more than you write it

删除代码的频率要高于编写代码

Farhan Thawar: "We have a Delete Code Club. We can almost always find a million-plus lines of code to delete. Everything gets easier - the codebase loads faster, it's easier to understand." Create dedicated time or teams focused solely on removing unused code. Deletion improves velocity and clarity.

Farhan Thawar：“我们有一个‘代码删除俱乐部’。几乎总能找到超过一百万行可以删除的代码。一切都会变得更简单——代码库加载更快，也更容易理解。”安排专门的时间或组建专门的团队，专注于移除未使用的代码。删除代码能提升交付速度和代码清晰度。

Tech debt is visible to users

技术债务会被用户感知到

Matt Mullenweg: "You can see [tech debt] in the interface or how their products integrate with themselves." Fragmented UIs and poor integration between features are user-facing symptoms of accumulated debt. Look for inconsistencies to identify where debt has accumulated.

Matt Mullenweg：“你可以从界面或产品内部的集成方式中看到[技术债务]的存在。”碎片化的UI以及功能间糟糕的集成是债务累积的面向用户的症状。寻找不一致之处，以确定债务累积的位置。

Quantify the value of paying down debt

量化偿还债务的价值

Casey Winters: "The most impactful projects are the hardest to measure, so they get chronically underfunded. Build custom metrics to show the value, run small tests that prove the worthwhile-ness of the investment." Create custom metrics and run experiments to demonstrate business value. Align with engineering and design to present a unified front.

Casey Winters：“最具影响力的项目最难衡量，因此长期得不到足够的资金支持。制定自定义指标以展示价值，开展小型测试来证明投资的合理性。”创建自定义指标并进行实验，以展示业务价值。与工程和设计团队协同，统一口径进行汇报。

Fix bugs immediately, don't backlog them

立即修复漏洞，不要积压

Geoff Charles: "We don't have a bug backlog. We fix every bug once they're surfaced almost." Assign bugs directly to the engineer on call to ensure immediate pain awareness. Bug backlogs become graveyards.

Geoff Charles：“我们没有漏洞积压。几乎所有漏洞一旦被发现就会立即修复。”将漏洞直接分配给值班工程师，确保他们即时感知问题的影响。漏洞积压会变成无人问津的“墓地”。

Debt ceilings innovation

债务会限制创新

Eeke de Milliano: "Sometimes teams are just getting bogged down by urgent work - too much tech debt, bugs, instability. There's no way they can focus on bigger, creative stuff if they're heads-down dealing with incidents all day." Diagnose when a team is stuck in a "hierarchy of needs" trap. Prioritize debt reduction to free up headspace for creative work.

Eeke de Milliano：“有时团队会被紧急工作拖累——太多技术债务、漏洞和不稳定问题。如果他们整天都在埋头处理故障，就根本无法专注于更具创造性的重大工作。”判断团队是否陷入了“需求层次”陷阱。优先削减债务，为创造性工作腾出精力。

Tech debt is a champagne problem

技术债务是“奢侈的烦恼”

Julia Schottenstein: "We would be so lucky to have tech debt because that means people are using the product. What we didn't need at launch was a distributed scheduler - we had no users." Build the simplest, most naive version first. Accept debt as a trade-off for getting product into users' hands.

Julia Schottenstein：“如果我们有技术债务，那简直太幸运了，因为这意味着有人在使用我们的产品。我们在发布时不需要分布式调度器——当时我们根本没有用户。”先构建最简单、最基础的版本。接受债务是将产品推向用户所付出的代价。

Plan for dark tunnels

为“黑暗隧道”做好规划

Melanie Perkins: "We thought it would take six months... it took two years of not shipping any product." Major rewrites are "dark tunnels" that stall shipping. If you must do them, gamify the work to maintain team momentum during the long slog.

Melanie Perkins：“我们原以为需要六个月……结果花了两年时间，期间没有发布任何产品。”重大重写就像“黑暗隧道”，会阻碍产品发布。如果必须进行重写，可将工作游戏化，以在漫长的过程中维持团队动力。

Design for 1-2 years out

为1-2年后的需求做设计

Austin Hay: "Think one to two years down the road about what we're going to need. When setting up tools, ask: 'What happens a year from now if I don't change anything?'" Implement foundational elements like SSO or proper data schemas early to avoid catastrophic migrations later.

Austin Hay：“提前1到2年思考我们未来的需求。在设置工具时，问问自己：‘如果我在未来一年都不做任何改变，会发生什么？’”尽早实施SSO或合适的数据架构等基础元素，以避免日后出现灾难性的迁移工作。

Questions to Help Users

用于帮助用户的问题

"Is this debt blocking critical business needs, or is it a slower-burning issue?"
"What percentage of engineering time is going to maintenance vs. new features?"
"Have you tried to estimate how long a rewrite would actually take? Who made that estimate?"
"What would happen if you did nothing for another 6 months?"
"Is there a way to incrementally improve this rather than rewriting?"
"How would you quantify the cost of this debt to stakeholders?"

“这笔债务是在阻碍关键业务需求，还是属于缓慢发酵的问题？”
“工程团队的时间有多少比例用于维护，多少用于新功能开发？”
“你有没有尝试估算重写实际需要多长时间？是谁做出的估算？”
“如果未来6个月不采取任何行动，会发生什么？”
“有没有办法通过增量改进来解决这个问题，而非重写？”
“你会如何向利益相关方量化这笔债务的成本？”

Common Mistakes to Flag

需要指出的常见错误

Planning a full rewrite - Rewrites almost never work as planned. They take 2-3x longer than estimated and you must support both systems simultaneously
Treating tech debt as engineering's problem - This is product debt. PMs should own it alongside engineers
Letting bug backlogs accumulate - Bug backlogs become graveyards. Fix immediately or decide not to fix at all
Over-engineering before product-market fit - Debt is a champagne problem. Build naive solutions first and accept debt as the cost of learning
Not quantifying the cost - Tech debt investments get underfunded because their value isn't measured. Build metrics and run experiments to prove ROI

规划完全重写 - 重写几乎从来不会按计划进行。所需时间是估算的2-3倍，而且你必须同时维护两个系统
将技术债务视为工程师的问题 - 这是产品债务。产品经理应与工程师共同承担责任
任由漏洞积压 - 漏洞积压会变成无人问津的“墓地”。要么立即修复，要么决定完全不修复
在产品-市场匹配前过度设计 - 债务是“奢侈的烦恼”。先构建基础解决方案，接受债务是学习的成本
不量化成本 - 技术债务相关的投资得不到足够资金，因为其价值未被衡量。制定指标并开展实验以证明投资回报率

Deep Dive

深入探讨

For all 20 insights from 18 guests, see

references/guest-insights.md

如需获取来自18位嘉宾的全部20条见解，请查看

references/guest-insights.md