但它明明还能工作
软件在运行。
不只是“勉强能跑”。客户能够 Login，核心流程完成，Dashboard 能加载，Feature 继续上线。也许还有 Monitoring、CI/CD、自动化 Test、Sonar、现代 UI，以及一支对 Incident 很有经验的 Team。
然后 Architect 说：
这个系统已经结构性 Erode。
Stakeholder 最自然的回答是：
但它明明还能工作。
这句话不是愚蠢，也不是对 Architecture 的敌意。
它描述了真实 Evidence。
系统确实还在创造价值。
问题只在于：“今天能工作”与“明天还能低风险地改变”不是同一个属性。
同一个系统的两个属性
Section titled “同一个系统的两个属性”Big Ball of Mud 最容易被误解的原因之一，是人们把两个质量维度混在一起。
第一个维度是当前功能状态：用户今天能不能完成任务？业务流程是否可用？SLA 是否达标？Release 是否还能发生？
第二个维度是结构性可变更能力：下一次重要 Change 需要理解多大的 Context？Regression Radius 多大？多少 Team 必须同步？是否依赖少数 Expert？成本与 Lead Time 能否预测？
这两个维度有关系，但不是同一个东西。
一个系统今天可以极其稳定，却越来越难修改。
反过来，一个架构结构良好的系统也可能因为某个业务 Bug 今天发生故障。
因此，“它还能工作”并没有推翻 Architecture Diagnosis。
它只是回答了另一道问题。
Functional Stability 说明系统今天的价值；Changeability 说明系统对未来变化的能力。
Stakeholder 看到 Value，Architect 还看到斜率
Section titled “Stakeholder 看到 Value，Architect 还看到斜率”Stakeholder 合理地关注当前 Business Value：Revenue、Customer、Feature、SLA、Deadline、Incident、Budget。
Architect 还必须关注另一个量：变化趋势。
系统每一次 Change 的理解成本是在稳定，还是越来越高？Lead Time Variance 是收敛，还是扩张？过去需要一个 Team 的修改，今天是否常常牵动三个 Team？
这可以被理解成“斜率”。
Stakeholder 看到当前坐标：系统今天在哪里。
Architect 还试图判断：按照当前结构继续演化，未来会往哪里走。
这两种视角都合理。
冲突发生在 Architect 用“未来结构风险”要求今天付出真实 Budget，而 Stakeholder 手里最强 Evidence 仍然是“系统目前工作”。
Software Development 的测量问题
Section titled “Software Development 的测量问题”如果一台工厂设备每小时从生产 100 件下降到 60 件，Productivity Decline 很容易看到。
Software Development 没有这样简单的 Unit Cost。
Feature 不是相同螺丝。每一个 Requirement 都带着不同 Domain Knowledge、不同 Unknown、不同 Integration、不同 Risk。
因此，说“Team 比去年慢了 20%”本身并不能证明 Architecture Erosion。
也许 Requirement 更复杂，也许 Regulation 增加，也许 Team 换人，也许 Process 变化，也许 Product 进入更困难的 Domain。
Petersen 对 Software Productivity Measurement 的 Systematic Map 也说明，Productivity 的测量本来就高度依赖 Context 与指标定义。Forsgren 等人的 SPACE Framework 更进一步强调，Developer Productivity 不能被压缩成单一 Activity Metric。
所以 Architecture Cost 很难从普通 KPI 中直接分离出来。
这不是借口。
这是测量现实。
“慢”——和什么比较？
Section titled ““慢”——和什么比较？”一个 Feature 花四周，算慢吗？
如果同一个 Feature 在另一个 Parallel Universe、同一 Team、同一 Requirement、但更好的 Architecture 中只需要四天，那当然慢。
现实里没有这个 Control Group。
因此，“四周太久”通常需要 Proxy 才能变成 Diagnosis。
例如：
- Change Radius 是否远大于业务范围？
- Regression Work 是否占 Lead Time 的很大比例？
- 是否反复等待同一个 Expert？
- 相似 Change 的 Duration Variance 是否很大？
- 是否经常因为 Hidden Dependency Rework？
- 是否存在不必要 Cross-Team Coordination？
这些信号并不单独证明 Big Ball of Mud。
但它们能比“感觉很慢”更接近结构问题。
Software 没有简单 Stückkostenrechnung
Section titled “Software 没有简单 Stückkostenrechnung”Ticket Count、Story Point、Lines of Code 都很容易被当作“产量”。
但它们不是统一单位。
一个 Ticket 可能只是 Label 文案，另一个可能涉及 Data Migration、Regulation、Security 和三个 External System。
今天完成十个 Ticket、下个月只完成六个，不能直接得出 Productivity 下降 40%。
这也是为什么“Developer 再快一点”通常不是诊断，而只是压力表达。
如果 Architecture 使每个 Change 需要更多 Context、Coordination 和 Regression，那么真正变化的是 Work Composition。
Team 仍然在做很多工作，只是越来越多工作没有以新 Feature 的形式可见。
Architecture 还有额外的可测量性问题
Section titled “Architecture 还有额外的可测量性问题”Business KPI 通常很可见：Budget、Deadline、Feature Count、Incident、Headcount、Revenue。
结构性 Change Cost 则分散在很多地方：额外 Understanding、Regression Surface、Expert Dependency、失去 Parallelism、Coordination Queue、Future Change Risk。
这些成本通常没有自己的 Jira Epic。
它们被分摊在每个 Ticket 中，因此很难在 Management Dashboard 上形成一条明显曲线。
于是产生一个 Communication Problem：Architect 感受到结构在恶化，Stakeholder 却没有同样可见的数据。
管理层没有立刻投入 Reconstruction，不一定意味着不在乎。
也可能是 Risk 从未被翻译成可以做 Business Decision 的语言。
不对称的 Business Case
Section titled “不对称的 Business Case”Architecture Improvement 的成本通常现在发生。
Refactoring 要占 Capacity，Migration 有 Risk，需要 Test，可能要同时维护新旧路径，还可能推迟 Feature。
收益却主要属于未来：下一个 Change 更快、Regression 更少、Onboarding 更简单、估算更稳定。
Future Benefit 是 Delay、Distributed、Uncertain。
Current Cost 是 Immediate、Visible、Certain。
这天然让 Status Quo 拥有更容易解释的 Business Case。
“现在不改”常常不是没有成本，而是它的成本被推迟并分散；“现在改”则需要立刻把成本集中到 Budget 上。
这也是为什么 Technical Debt Discussion 如果只说“代码会更干净”，很难竞争过一个确定的 Customer Feature。
“但它能工作”是真实 Evidence
Section titled ““但它能工作”是真实 Evidence”这里必须明确支持 Stakeholder 一次。
如果系统已经稳定运行多年，Change Demand 很低，Revenue 可靠，Risk 被有效控制，Replacement 计划明确，那么继续运营完全可能是理性的。
Architecture 不是宗教。
不能因为内部结构“丑”，就自动要求 Organisation 批准大型 Modernization。
“它能工作”意味着：当前补偿机制至少在某种程度上有效。
Expert、Test、Process、Review、Release Ritual、Manual Check 共同维持了系统稳定。
真正要分析的是：这种稳定性的成本是否仍然可接受，以及 Future Change 是否还会触发更高结构成本。
增加人手不会自动解决
Section titled “增加人手不会自动解决”当 Delivery 变慢，一个经典 Management Reflex 是加人。
有时这当然有效。
在 Modular System 中，如果 Work 可以分成相对独立 Change Space，更多 Team 能够平行推进。
在 Big Ball of Mud 中，额外 Team 却可能共享同一 Global State、Shared Service、Expert、Integration Environment 和 Release Window。
于是 Headcount 增加，Communication Edge 也增加。
新的 Developer 需要 Onboarding，更多 Change 同时竞争 Shared Area，Key Person Review Queue 变长。
这就是为什么 Technical Dependency 会直接影响 Organisational Scalability。
更多 Developer，几乎没有更多 Throughput
Section titled “更多 Developer，几乎没有更多 Throughput”如果 Bottleneck 是 Coordination 而不是 Coding Capacity，新增 Developer 的边际收益会很低。
一个十人 Team 不一定比五人 Team 多一倍 Output，尤其当大家都必须等待同一个 Expert 或在同一 Shared Component 上修改。
这不是简单的“Brooks’s Law 适用于一切”。
而是一个具体结构问题：更多人只有在 Work 可以被分离时，才容易转化成 Parallelism。
如果 Architecture 没有提供独立 Change Space，Organisation 购买的是更多参与者，而不是自动购买更多独立吞吐。
Parallel Teams 需要 Parallel Boundaries。
否则更多人只会增加 Coordination。
“以前的人就是更强”
Section titled ““以前的人就是更强””当系统过去似乎开发得更快，另一个常见解释是：
以前那些 Developer 就是更强。
也许他们真的非常优秀。
但如果“高效率”依赖同一批人拥有十年隐式历史 Knowledge，那么这本身也是 Architecture Signal。
今天的新 Developer 并不是只在与老 Developer 的 Skill 竞争。
他还缺少那些从 Incident、Workaround、Customer Sonderfall 和历史 Release 中累积出来的 Mental Map。
一个系统如果只有在最早一代 Expert 存在时才显得简单，不能因此证明系统本身简单。
它可能只是把 Architecture Knowledge 存进了人脑。
KPI 真空
Section titled “KPI 真空”如果 Organisation 没有任何 Metric 描述 Changeability，它就会自然使用已有 Metric：Velocity、Story Point、Ticket Count、Deadline Hit Rate、Utilization。
这些指标可以回答某些问题。
但它们不能直接回答 Architecture Health。
于是当 Throughput 下降，Diagnosis 容易落在人、Planning 或 Process 上。
这并不是 KPI“错误”。
而是存在一个 KPI Vacuum：最重要的结构属性没有被观测。
更有帮助的 Proxy 可能包括：
- Change Lead Time 分布；
- Cross-Team Dependency 数量；
- Regression Effort；
- Rework；
- Key-Person Wait Time；
- Affected Scope；
- Upgrade Duration；
- Onboarding Time。
这些仍然不直接等于 Architecture Quality，但更靠近实际 Changeability。
每个症状都有局部解释
Section titled “每个症状都有局部解释”Big Ball of Mud 很难被看见，还有一个原因：每一个单独事件都可以被合理解释。
一个 Release 延迟？Requirement 变了。
一个 Regression？Developer 犯错。
一个 Expert 被叫来？那个区域比较特殊。
一次 Estimate 爆掉？Ticket 不清楚。
新人六个月还不独立？Domain 很复杂。
每个解释都可能是真的。
系统级 Pattern 就藏在大量局部合理解释里。
只有把事件跨时间聚合，才可能看到：这些看似不同的问题反复指向同一组 Dependency、Boundary、Shared State 和 Knowledge Bottleneck。
Big Ball of Mud 往往不是一个巨大 Signal，而是很多被分别解释掉的小 Signal。
Lost in Translation
Section titled “Lost in Translation”Engineering 与 Stakeholder 经常不是在争论同一件事。
Engineer 说：
Coupling 很高，Boundary 失效。
Stakeholder 听到：
Developer 想做技术 Cleanup。
Engineer 说：
我们需要 Architecture Reconstruction。
Stakeholder 听到：
你要停止 Feature 几个月，但无法证明 Revenue。
这是 Translation Gap。
Architecture Risk 必须连接 Business Consequence：Lead Time、Predictability、Release Risk、Opportunity Cost、Regulatory Response、Key-Person Dependency。
两种视角都描述真实系统。
成熟 Architecture Communication 的任务不是要求 Stakeholder 学 Dependency Theory，而是建立这两种视角之间的因果桥。
技术警告也可能失去 Signal Value
Section titled “技术警告也可能失去 Signal Value”如果 Developer 多年来不断说：
Legacy 很糟，我们必须 Refactor。
但系统仍然运行、Feature 仍然交付、客户仍然续约，那么 Stakeholder 合理地会降低这些 Warning 的权重。
特别是当 Warning 没有可验证 Prediction。
如果每个 Release 都被称为“下一次可能彻底崩”，但下一次仍然成功，技术语言就会出现 Alarm Fatigue。
更有效的表达是具体 Observation：
过去八次这个区域的 Change 都涉及三个 Team；Regression Phase 平均占 Lead Time 40%；两次 Delay 都等待同一个 Expert。
这种信息可以被 Challenge，也可以被 Measurement 更新。
Architecture Warning 如果永远不能被验证，最终会失去信号价值。
改变本身有真实风险
Section titled “改变本身有真实风险”Status Quo 有问题，并不意味着 Change 自动更安全。
Modernization 会带来 Real Risk：新 Bug、Data Migration、Parallel Run、Training、Opportunity Cost、Operational Complexity。
一个 Critical System 如果今天稳定，Organisation 对大规模 Change 保守完全可能理性。
这也是为什么 Architecture Proposal 必须讨论 Transition Risk，而不只是 Target State。
“新结构更好”只是答案的一部分。
Stakeholder 还必须相信从旧结构走到新结构的路径足够安全。
Too big to fail——但不是 Financial Crisis 类比
Section titled “Too big to fail——但不是 Financial Crisis 类比”某些 Software System 会因为 Business Criticality 变得“太重要，不敢大改”。
这里不是拿金融危机做严格类比，只是描述一个稳定机制。
系统越关键，Organisation 越怕 Reconstruction Risk。
越不进行根本 Change，旧结构越长时间累积。
结构越复杂，对 Expert 与特殊 Process 的依赖越强。
这些 Compensation 又让现状继续可运营。
于是 Criticality 与 Inertia 可能相互强化。
一个系统越重要，越需要 Changeability；但它越重要，也可能越难承担获得 Changeability 所需的改变。
到这里，心理机制才真正进入
Section titled “到这里，心理机制才真正进入”在解释 Stakeholder Resistance 时，人们很容易直接跳到 Status-quo Bias、Sunk Cost、Escalation of Commitment 或“Management 不愿承认错误”。
这些机制当然可能存在，而且有研究基础。
但如果一开始就用 Psychology 解释，会跳过更基本的现实：Stakeholder 可见的信息与 Engineer 可见的信息不同，Change Cost 是立即的，Architecture Benefit 是 Future 和 Uncertain 的。
只有先承认这个 Information / Economic Asymmetry，心理机制才应该进入分析。
否则我们只是把理性冲突人格化。
Defensive Routine，而不是“他们不想看”
Section titled “Defensive Routine，而不是“他们不想看””Argyris 传统中的 Defensive Routine，或近年对 Organizational Defensive Routine 的研究，提供了更细的视角。
当 Architecture Discussion 触碰过去 Decision、Leader、Investment 或 Team Identity，Organisation 可能形成避免深层讨论的 Routine。
问题被局部化：
这只是一个 Bug。
被技术化：
升级 Framework 就好了。
被推迟：
下一个 Program 再处理。
这些行为不需要有人“故意隐瞒”。
它们可以成为组织保护稳定与避免 Conflict 的正常机制。
可见目标与不可见结构竞争
Section titled “可见目标与不可见结构竞争”Quarter Goal 很可见。
Customer Deadline 很可见。
Revenue Commitment 很可见。
减少 Future Change Radius 的收益则很难直接展示。
当 Prioritization 发生时，Visible Goal 天然拥有优势。
这也是 Technical Debt Management 研究为什么重视 Incentive 与 Stakeholder Value Criteria。
结构工作如果不能与可见 Business Outcome 建立联系，就很容易在每个 Planning Cycle 里输掉。
不是因为没人知道它重要。
而是因为 Organisation 必须在今天可观察的 Value 与未来不确定的 Risk Reduction 之间选择。
一旦把维度分开，核心矛盾其实会消失。
软件今天可以工作。
同时：
软件未来可以越来越难改变。
两句话可以完全同时为真。
一个成熟 Architecture Discussion 不应该试图用第二句话否定第一句。
它应该问：
- 当前 Stability 是靠什么获得？
- 这些 Compensation 的成本是多少？
- Future Change Demand 多高？
- 当前 Structure 对未来 Risk 有什么影响？
这会把讨论从“系统到底好不好”转成更可决策的问题。
然后人开始离开
Section titled “然后人开始离开”当 Change 长期高风险、工作越来越多地用于理解 Historical Dependency、Modernization 反复失败时，技术问题可能逐渐进入 Human Dimension。
Frustration、Employee Silence、Turnover、Burnout Risk、Knowledge Loss 都可能成为更大 Socio-Technical Problem 的一部分。
这里仍然不能简单说“Architecture 导致 Burnout”。
但当 Key Person 离开，一个结构本就难以表达自己的系统会失去一部分隐式 Navigation Map。
Replacement 看到同一 Codebase，却没有同一 Mental Model。
从外部看，这可能只是 Personal Turnover。
从系统角度看，它也可能暴露 Architecture 对 Knowledge Concentration 的依赖。
这时，过去不可见的 Architecture Cost 终于变得可见。
通常也更昂贵。
这里没有明显坏人
Section titled “这里没有明显坏人”这可能是整篇最不舒服的结论。
Developer 的技术 Diagnosis 可以是真诚且正确的。
Architect 可以真实看到结构 Damage。
Product Owner 同时必须履行真实 Delivery Commitment。
Area Manager 要负责有限 Budget。
Auftraggeber 完全可以合理要求：一个仍然工作的 Critical System 不能因为“内部不好看”就进行高风险 Reconstruction。
Management 在不完整信息下也可能做出完全可理解的选择。
系统仍然可以停留在坏平衡里。
这不需要无知 Stakeholder、无能 Manager、懒惰 Developer 或恶意 Architect。
只需要不同 Information、不同 Time Horizon、真实 Economic Risk，以及一个核心结构属性很难直接观察的系统。
Psychological 与 Organisational Mechanism 可以随后稳定这个状态。
但它们不是一开始冲突存在的唯一原因。
问题并不明显
Section titled “问题并不明显”对 Developer 来说，Big Ball of Mud 可以每天直接体验。
他打开 Ticket，先要猜哪个 Service 真正负责；修改一个 Local State 又发现另外几个 Writer；修复远端 Regression；等待唯一懂某个区域的同事。
Architecture Problem 对他来说非常具体。
Stakeholder 看到的是另一个画面：一个仍然工作、仍然创造价值的 Asset。
它的 Operational Problem 看起来彼此独立：有些 Change 久，有些 Release 难，一些 Expert 特别重要，新人上手慢，新增 Headcount 没产生期待 Throughput。
每一个 Observation 都有 Alternative Explanation。
没有哪一个单独证明 Architecture Problem。
现在却要求 Stakeholder 投入真实资金、推迟 Feature、承担真实 Project Risk，去处理一个 Damage 很难直接观测，而 Future Avoided Cost 又无法精确证明的问题。
Resistance to Change 不自动意味着缺少洞察。它可以是对一个“成本可见、根因难观测、替代方案又充满不确定性”的问题做出的理性反应。
Status-quo Bias、Escalation of Commitment、Defensive Routine 和 Employee Silence 可以加剧局面。
但更早的冲突来自一个更基础问题：Organisation 到底能看到、测量什么？
系统正在运行。正因为如此，解释“为什么它仍然是一个问题”才这么困难。
- Arkes, H. R. & Blumer, C. (1985): The Psychology of Sunk Cost. Organizational Behavior and Human Decision Processes, 35(1), 124–140. DOI: 10.1016/0749-5978(85)90049-4.
- Auqui-Caceres, M.-V. & Furlan, A. (2026): Why do defensive routines persist in organizational contexts? Results from a two-year ethnographic action research. European Management Review. DOI: 10.1111/emre.70055.
- Berente, N., Salge, C. A. de L., Mallampalli, V. K. P. & Park, K. J. (2022): Rethinking Project Escalation: An Institutional Perspective on the Persistence of Failing Large-Scale Information System Projects. Journal of Management Information Systems, 39(3), 640–672. DOI: 10.1080/07421222.2022.2096545.
- Besker, T., Martini, A. & Bosch, J. (2022): The use of incentives to promote technical debt management. Information and Software Technology, 142, 106740. DOI: 10.1016/j.infsof.2021.106740.
- Bittencourt, J. P., Spínola, R. & Maciel, R. S. P. (2026): Stakeholder Value Criteria for Technical Debt Acquisition Decisions: An Empirical Analysis. ACM Transactions on Software Engineering and Methodology. DOI: 10.1145/3808227.
- Cataldo, M., Wagstrom, P. A., Herbsleb, J. D. & Carley, K. M. (2006): Identification of Coordination Requirements: Implications for the Design of Collaboration and Awareness Tools. Proceedings of CSCW 2006. DOI: 10.1145/1180875.1180929.
- Forsgren, N., Storey, M.-A., Maddila, C., Zimmermann, T., Houck, B. & Butler, J. (2021): The SPACE of Developer Productivity: There’s more to it than you think. ACM Queue, 19(1), 20–48. DOI: 10.1145/3454122.3454124.
- Hao, L., Zhu, H., He, Y., Duan, J., Zhao, T. & Meng, H. (2022): When Is Silence Golden? A Meta-analysis on Antecedents and Outcomes of Employee Silence. Journal of Business and Psychology, 37, 1039–1063. DOI: 10.1007/s10869-021-09788-7.
- Keil, M., Tan, B. C. Y., Wei, K. K., Saarinen, T., Tuunainen, V. & Wassenaar, A. (2000): A Cross-Cultural Study on Escalation of Commitment Behavior in Software Projects. MIS Quarterly, 24(2), 299–325. DOI: 10.2307/3250940.
- Luftman, J., Lyytinen, K. & Ben-Zvi, T. (2017): Enhancing the measurement of information technology (IT) business alignment and its influence on company performance. Journal of Information Technology, 32(1), 26–46. DOI: 10.1057/jit.2015.23.
- MacCormack, A., Baldwin, C. & Rusnak, J. (2012): Exploring the duality between product and organizational architectures: A test of the “mirroring” hypothesis. Research Policy, 41(8), 1309–1324. DOI: 10.1016/j.respol.2012.04.011.
- Petersen, K. (2011): Measuring and predicting software productivity: A systematic map and review. Information and Software Technology, 53(4), 317–343. DOI: 10.1016/j.infsof.2010.12.001.
- Samuelson, W. & Zeckhauser, R. (1988): Status quo bias in decision making. Journal of Risk and Uncertainty, 1, 7–59. DOI: 10.1007/BF00055564.
- Sánchez-Gordón, M., Colomo-Palacios, R., Sanchez Gordon, A. & Hubin, A. (2026): The role of voice and silence behaviors in software development: a structural equation modeling analysis. Information and Software Technology, 190, 107972. DOI: 10.1016/j.infsof.2025.107972.
- Wiese, M. & Borowa, K. (2023): IT managers’ perspective on Technical Debt Management. Journal of Systems and Software, 202, 111700. DOI: 10.1016/j.jss.2023.111700.