编程与软件工程erikbern.com编辑精选
为什么软件项目比你想象中更耗时：一个统计模型
Why software projects take longer than you think – a statistical model
2019 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
作者用统计模型解释为什么软件项目总是超期：把任务的“膨胀系数”（实际耗时/预估耗时）建模为对数正态分布，其长尾意味着不确定性大的任务会主导整个项目的平均耗时，甚至对完全未知的任务而言平均耗时趋于无穷。文章还讨论了如何用这种统计视角改进估算和排期。
为什么经久不衰：它把“软件总是做不完”的日常痛点变成可量化的统计规律，多年后重读仍能帮助开发者和管理者更理性地面对估算与承诺。
HN 评论精选
真实数据验证了对数正态模型：估算本身是准的，超期来自不可预知的乘性因素。
我们曾对多年内部项目做详细的时间追踪，发现无论任务预估是 1 小时还是 13 小时，实际完成时间都精确服从对数正态分布，尺度参数恰好是预估时间。这说明开发者其实很了解问题类型，只是有些任务存在乘性因素（比如一个 bug 其实是两个 bug），不应把超时 10 倍简单视为预测失败。
jbay808查看英文原文
> A reasonable model for the “blowup factor” (actual time divided by estimated time) would be something like a log-normal distribution. Interestingly, we did extensive time tracking on a multi-year in-house software project and collected data comparing the estimated completion time of tickets with their actual time. The software department was under a lot of pressure to improve their forecasting, and were somewhat despairing that their estimates were off by a factor of about 1.6 on average, and sometimes a factor of 10 or more. This persisted in the face of all attempts to improve calibration. Managers were worrying that developers had no idea how long a task would take and estimation was futile. When we plotted the data, in all cases, the actual time was very accurately fit by a lognormal whose scale parameter was precisely the predicted completion time. That is, whether the tickets were predicted to take 1 hour, 3 hours, 13 hours, or whatever, the histogram of their actual completion times followed the exact same shape but with a corresponding scale change on the x axis. This told me that the developers actually have a really good understanding of the class of problem they're dealing with when they start a task. But sometimes tasks have multiplicative factors that make them take longer than you expect. Sometimes the bug turns out to be two bugs, and so on. Based on this analysis, I urged them not to consider it a prediction failure when a ticket takes 10 times longer than expected; that's just a property of the lognormal distribution, and that estimate likely did a good job of reflecting all available information at the time they made it. Instead of changing the estimates, I suggested that we pick a safety factor for external facing commitments that reflects this distribution. Padding the estimate by 1.6 factor gives the mean, but if you want to make a commitment you can take to a customer, you can just extend the lognormal up to 95% confidence or 99% confidence or however trustworthy your promised commitment needs to be. Of course, a 99% confidence interval on a lognormal is a pretty big factor. But if that's better than running late, it is what it is. Another interesting thing is that you'd expect, by the central limit theorem, that sufficiently large tasks would eventually become normally distributed rather than lognormal, because they're composed of a large number of subtasks. But it turns out that lognormals are a pretty pathological case; sums of n lognormals can continue to look nearly lognormal until n becomes really, really large.
诚实地拒绝给出不可靠的估算，是工程师的职业操守。
专业软件工程师的重要素质是敢于说“我还不够了解问题，无法给出哪怕粗略的估算，我可以花一天调研后再汇报”，或对依赖不明 API 的部分坚持先解决前提条件。你需要忍受当面说“我不知道”并顶住压力，否则会不断给出偏差 10 倍的估算，耗尽信誉并把自己逼垮。只要你清晰地表达专业需求，人们通常是讲理的。
afarrell查看英文原文
An important aspect of being a professional software engineer is having the backbone to sometimes say things like: - “I don’t know yet enough about the problem to give you even a rough estimate. If you’d like, I can take a day to dig into it and then report back.” - “This first part should take 2-3 days. 5 on the outside. But the second part relies heavily on an API whose documentation and error messages are in Chinese and Google Translate isn’t good enough. I’d need to insist on professional translation in order to even estimate the second part.” - “The problem is tracking down a bug rather than building something, so I don’t have a good way of estimating this. However, I can timebox my investigation and if I’ve not found the cause at the end of the timebox, can work on a plan to work around the bug.” You need to be willing to endure the discomfort of looking someone in the face, saying “I don’t know”, and then standing your ground when they pruessure you to lie to them. They probably don’t want you to lie, but there is a small chance that they pruessure you to. If you don’t resist this pruessure, you can end up continually giving estimates that are 10x off-target, blowing past them as you lose credibility, and your running your brain ragged with sleep-deprivation against a problem you haven’t given it the time to break down and understand. But when you advocate clearly for your needs as a professional, people are generally reasonable.
用粗粒度分级、拆分大任务和留足缓冲的季度承诺制，是可行的估算实践。
我见过一家估算做得很好的公司：所有任务按 T 恤尺码分级，超过“大”（约数人月）的任务视为无界，要拆成一系列有独立价值的小项目；每季度只承诺能完成的部分，刻意少承诺多交付，日程留出 1/3 到 1/2 的余量应对突发事务，还有技术债清单作为提前完成时的奖励。
bunderbunder查看英文原文
I've been one place that I thought was really good at software estimation. Their system was: Everything gets a T-shirt size. Roughly, "small" is no more than a couple person-days, "medium" is no more than a couple person-weeks, "large" is no more than a couple person-months. Anything beyond that, assume the schedule could be unbounded. Figure out how to carve those into a series of no-larger-than-large projects that have independent value. If they form a series of iterations, don't make any assumptions about whether you'll ever even get around to anything but the first one or two. That just compromises your ability to treat them as independent projects, and that creates risk that you find yourself having to worry about sunk costs and writing down effort already expended when it eventually (and inevitably) turns out that you need to be shifting your attention in order to address some unforeseen business development. At the start of every quarter, the team would commit to what it would get done during that quarter. There were some guidelines on how many small, medium or large projects they can take on, but the overriding principle was that you should under-promise and over-deliver. Lots of slack (1/3 - 1/2) was left in everyone's schedule, in order to ensure ample time for all the small urgent things that inevitably pop up. There was also a log of technical debt items. If the team finished all their commitments before the end of the quarter, their reward was time to knock things off that list. Best reward ever, IMO.
超期的主要来源是项目外的干扰，估算时应显式计入干扰时间。
过去十年的经验告诉我，难点往往不是估算项目本身要多久，而是会有多少其他事情插进来：线上 bug、其他团队的求助会议、生产事故等。所以我的做法是先估算“不受干扰全职投入”所需时间，再按每天被干扰的小时数折算，并直接告诉干系人“这是全职投入的时间，现实里大概要乘以 2”。
godot查看英文原文
In my experience from the past decade, it is often the case that, the difficult thing isn't estimating how much time the proposed project takes to build (this is the difficult part for some devs though), but it's how much other stuff comes up. Stuff includes everything not related to your project. E.g. your last project that is now on prod, where bugs were reported and need to be fixed. Another team needs your expertise on something and next thing you know you're in a 2 hour meeting with them, and also reviewing their 1000-lines PR. Maybe a real production fire is happening and you have to help and it takes you the next 2 full days on it. Because of this, my general approach when estimating a project in my head is how much time I know it would take me if I get to work full time on it with nothing else on my plate. Then I can better estimate how much time realistically it would take after factoring in X number of hours per day on distractions. In many cases I also communicate with the stakeholders (PMs, biz ops, leads) directly "This is how long it would take me if I dedicate full work days on it" and let them take it at face value too. (It's a sentence that usually ends with "So realistically probably [2x of what I just said]")
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选