90–90 法则
前 90% 的代码耗费 90% 的开发时间，剩下 10% 又耗费另外 90%。
显示原始英文内容
The Ninety-Ninety Rule
The first 90% of the code accounts for the first 90% of development time; the remaining 10% accounts for the other 90%.
Takeaways
- The final parts of a project (polishing, edge cases, integration, bug fixes) often take far more effort than anticipated, often as much as the initial development.
- What looks like the 'finishing touches' involves many tricky problems and unknowns.
- Reaching a 'mostly done' state can create optimism, but the rule warns that 'almost done' often means only halfway in terms of time.
Overview
This rule quantifies the extent to which projects get stuck in the final phase. Often, teams make good progress at the start, building core functionality, which leads to optimism. Then integration, corner cases, performance tuning, and bug fixing consume an unexpectedly large amount of time, often equal to or greater than what has already been spent.
In practical terms, this rule advises that the last bit of a project is not a small bit. You should plan for a significant effort in finishing, polishing, and delivering.
It is also related to Hofstadter's Law, as it is another way our estimates fall short. We do not realize how hard that last leg is.
Examples
A team develops a new app. In three months, the core features are done, and they hit "90% of the functionality." Everyone expects to ship in one more month. Instead, integration testing reveals that multiple modules do not talk correctly, specific edge inputs crash the app, memory usage is too high. That final "10%" takes another three months.
When implementing a new website, you get a basic version up quickly (login, basic pages). The last bits: cross-browser fixes, responsive design adjustments, accessibility improvements, writing tests, and performance improvements seem like 10% of the work, but they take as much time as the main coding.
The rule is an important reminder: Do not celebrate too early!
Origins
Credited to Tom Cargill of Bell Labs, and popularized by Jon Bentley's September 1985 "Bumper-Sticker Computer Science" column in Communications of the ACM. It was originally called the "Rule of Credibility", a name which did not stick.
It became popular in programming circles and is frequently referenced in discussions of why software is usually delivered late or why "90% done" claims can be misleading.
核心含义
项目早期的“基本功能完成”通常不等于真正完成。集成、边界情况、测试、性能、部署、文档和上线后的修复，往往集中暴露在最后阶段。
估算时应把这些收尾工作显式列出来，避免用一个“开发完成百分比”制造虚假的进度感。
实践例子
页面和主流程已经能运行，但权限、异常恢复、迁移脚本和自动化部署都没有完成。团队以为只剩 10%，实际工作量可能与前面一样大。
来源与边界
这条经验常被归于 Tom Cargill，也常被当作对软件估算乐观偏差的幽默总结。它不是精确比例，而是提醒我们识别最后阶段的隐性工作。