职业与工作方法iism.org
用任意截止日期驱动工程师是摧毁价值的错误
Driving engineers to an arbitrary date is a value destroying mistake
2020 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章认为，把工程师强行推向一个拍脑袋定下的截止日期，会迫使团队砍质量、赶工，最终摧毁产品价值。作者用实际案例说明不合理的日期压力如何导致技术债和劣质交付。文章在 2020 和 2021 两次登上 Hacker News 首页，引发了关于截止日期价值与危害的长期争论。
为什么经久不衰：截止日期与工程质量的张力是软件行业永恒的难题，正反双方的高质量讨论让它至今仍是管理者与工程师都值得一读的经典辩题。
HN 评论精选
截止日期的价值在于强制优先级排序，但压力应施加在选型决策而非执行层面
作为一个自己写大部分代码的小软件公司经营者，我其实不同意这篇文章。设定期限有很大价值，因为它逼你排优先级。一旦意识到没时间同时交付 X、Y、Z 功能，你就会比较它们的影响/复杂度/风险，挑最有价值的先做。没有优先级，很容易陷入无休止加小改进、永远发布不出可卖产品的循环（游戏业有著名反例，如《永远的毁灭公爵》）。但时间压力应该只施加在决策层面：一旦决定用某框架做某功能，就别再逼开发者砍单元测试、每周干 60 小时——那说明你当初就该选复杂度减半、用户价值八成的功能 Z。
john_moscow查看英文原文
As a person who runs a small software business, coding most of the functionality myself, I actually disagree with the article. There is a huge value in setting deadlines because they force you to prioritize things. Once you realize that you don't have the time to ship features X, Y and Z, you start comparing their impact/complexity/risks, pick the most beneficial one, and ship it before it's too late. Without prioritization it's very easy to get stuck in a loop of endlessly adding small improvements/testing new ideas, but never releasing the final sellable product. There are a few notorious examples from the game industry where no time pressure lead to either no product, or a hopelessly late-to-market product (e.g. Half-Life 3, Duke Nukem Forever). There are more smaller examples where entire teams endlessly juggle the code between web frameworks, as they come in and out of fashion, and neglect more user-impacting features. That said, most of time pressure should only be applied at the decision-making level. Once you have decided to ship feature X with framework Y, it's useless to nag on your devs to do it in half the time by dropping unit tests, or doing 60-hour work weeks. Instead, you should have picked feature Z with 50% the complexity and 80% user impact.
问题不是日期本身，而是不合理日期与缺乏信任；管理得当的日期是宝贵的约束
这篇文章凸显的是称职的技术管理的重要性。问题不在于日期本身，而在于不合理的日期、缺失的反馈回路和管理链上信任的缺失——文中的例子只是经典“雪茄高管”的稻草人。取消日期绝不是正解，那等于让每个 PM 和销售随意插入一时兴起的想法。相反，一个管理得当的日期是极有价值的约束，全团队可以据此做取舍；前提是管理层信任团队，工程师理解业务全局，从而找到既不牺牲质量又能缩短交付时间的创造性方案。
dasil003查看英文原文
This post highlights the importance of competent technical management. The problem is not arbitrary dates, it's unreasonable dates with inappropriate feedback loops and lack of trust throughout the management chain. The example given is a strawman of a classic cigar-chomping executive whose philosophy comes largely from unskilled, fungible-labor economies. Taking away the date is definitely not the right move. Now you've given every PM and sales guy carte blanche to throw whatever flavor-of-the-moment idea comes in their head. The team will be churning constantly to keep up with the requirements and then someone will suggest, "I know, let's do scrum!" so now we can all enjoy the stress of unreasonable deadlines on a continuous rather than waterfall basis. To the contrary: a properly-managed date is an incredibly valuable constraint which the entire team can use to make tradeoffs against. To make it work management needs to trust the team, and engineers need to understand the larger business picture because they are the ones with the knowledge to find creative solutions that actually work and decrease time to value without compromising technical quality or long-term maintainability.
40 年老兵自述几乎从未按期交付过，但完全无期限同样危险
坦白：做了 40 多年软件，我只有一次按期完成——那还是我职业生涯第一个项目，150 天只差一周，而且当时市场部还想再提前 30 天。“排期博弈”真正的输家是客户，他们拿到满是 bug 的劣质产品；公司则因偿还质量债而陷入漫长的更新周期。但放任项目自由发挥也不一定更好，“好好做、总有一天会发布”缺乏交付的紧迫感，我见过数千万美元的项目因此失败。
kabdib查看英文原文
Confession time: In 40+ years of doing software, I've met my schedule once. Actually, that's a lie. I missed by a week on a 150-day long project, my very first project at my very first real company, and that's the closest I ever got with my own estimates. And on that project, marketing wanted it pulled into 30 days (and to hit that 150 days I was doing all-nighters and basically killing myself, so it wasn't a very good schedule to begin with). [For the curious, it was a game cartridge]. The real losers of "schedule chicken" are the customers, who receive buggy and bad products. The company will suffer long product update cycles because of the effort needed to stay ahead of the quality debt. Explaining this to a manager who's never even read even one of his copies of The Mythical Man-Month can be tough. Things aren't necessarily better when you let a project freewheel. "You'll ship someday, just do a good job and get it right" doesn't necessarily translate into the urgency to ship a product, and I've seen efforts on the scale of tens of millions of dollars fail. Other arbitrary dates include things like shows (well, what is the real cost of missing that show versus shipping something buggy to bad reviews?) or holidays (hitting Christmas used to be a good excuse for schedule pressure in the game industry, much less of an excuse now). [Anecdata: Years ago there was a manager at Microsoft who told his team to ship by some arbitrary date, which turned out to be when he was planning to go on a long vacation. I'm happy to say that Microsoft fired him.]
VFX 行业的硬性期限实践：用 A/B 团队对冲新技术风险，期限本质是控制成本
我在 VFX 行业时 deadline 是硬性的——印在电影海报上的上映日期不会变。流程中有些部分容易估算，但每部电影总有实验性的新东西。常见做法是让 2-3 个团队同时解决同一问题：一个用成熟技术，一两个尝试新方法；新方案不行就退回老路，效果差些但能保交付。多数开发团队没有这种 A/B 团队的资源，但这确实是控制风险的方式。片方用上映日期控制成本，否则有些导演会永远做下去——很多电影尤其是特效片，从来不是“完成”，只是到了期限交出现有的东西。
onion2k查看英文原文
The problem that the article doesn't address is that users don't actually seem to mind using terrible software so long as it solves the problem they face better than not using it. I could list literally hundreds of half-assed, broken, bloated applications that I've encountered in the past 25 years that have done very well simply because they kind of solve a problem a bit for the user. Pushing out something completely broken that doesn't do what it's supposed to is definitely not going to work (duh!). Pushing out an app that solves the problem of managing shopping lists that has a bug where it doesn't work given a particular set of circumstances will still lead to many people using it if the users don't have any alternatives and it's better than using a piece of paper. Software quality is important to companies because it means that they can spend more time building features instead of fighting fires, and because low quality represents a threat that a competitor could launch a better, less buggy app. Users mostly don't care so long as the app works well enough to do what they need it to do (but they're not dumb, they'll still pick the least buggy option if there are alternatives..). A high level of quality in software is not important unless you're entering an already well-served market. I wish it was.
延期是所有新型工程项目的共性，并非软件独有，指责软件是双重标准
奇怪的是，软件工程师总被单独拎出来指责延期，而我的印象是所有新型工程项目都有同样的问题——军用民用硬件和基础设施项目超支超期数月数年是常态。有人能拿出实证证据证明软件项目比同等预算和独创性的硬件项目延期更多吗？建筑工程常被拿来作负面对比，但那其实是工程学中一个独特的子领域：约束和变量高度同质，因此能被研究、理解并掌握，形成接近大规模生产的学科；软件中约束同样同质的领域（如标准商业网站）也确实出现了更可控、模板化的做法（如 WordPress）。
stupidcar查看英文原文
It seems strange to me that software engineers are so frequently singled out for schedule slippage, when the impression I get is that every novel engineering project suffers from the exact same problem. Projects to design and build new military and civilian hardware and infrastructure always involve budget and schedule overruns of months or years. Can anyone provide convincing empirical evidence that software projects are delayed more than hardware projects of equivalent budget and distinctiveness from previous solutions? A negative comparison often seems to be made between software engineering and construction, but it seems to me that the latter is a unique subfield of engineering, where you have an unusually large number of projects with a roughly homogenous set of constraints and variables. This has allowed those constraints and variables to be studied, understood and mastered to produce a discipline that more closely resembles mass-production. And in those subfields of software that also involve more homogenous constraints, such as the production of standard commercial websites, you do see a more controlled and templated approach, using tools like Wordpress.
历次讨论
同类还值得读
用十年时间自学编程（1998）
Teach Yourself Programming in Ten Years (1998)
Peter Norvig 1998 年的经典文章，回应“21天/24小时学会编程”一类速成书，主张真正精通编程需要约十年持续、有意识的练习。
职业与工作方法上首页 11 次 · 2007–2025norvig.com编辑精选如何成为一名程序员：简短、全面而个人的总结
How to be a Programmer: A Short, Comprehensive, and Personal Summary
一篇广为流传的程序员成长指南，作者以个人经验系统总结了成为优秀程序员所需的各项技能——从调试、测试、沟通到团队协作与身心健康。
职业与工作方法上首页 6 次 · 2008–2015samizdat.mines.edu编辑精选不要自称程序员
Don't Call Yourself a Programmer
经典职业建议文章劝软件工程师不要把自己局限在“程序员”这个标签上，而要从公司业务角度说明自己创造的价值；文中讨论了成本中心与利润中心、头衔、求职与职业选择，也顺带批评了学术界的价…
职业与工作方法上首页 5 次 · 2011–2021kalzumeus.com编辑精选创作者的日程与经理的日程
Maker's Schedule, Manager's Schedule (2009)
Paul Graham 在这篇文章里把时间表分成两类：管理者的日程以小时为单位，会议可以填满一天；创作者（程序员、写作者等）的日程则以半天为单位，需要长时间不被打断的连续块。
职业与工作方法上首页 5 次 · 2009–2021paulgraham.com编辑精选为什么程序员的薪酬不与生产力成正比
Why programmers are not paid in proportion to their productivity
讨论为什么程序员的薪酬往往不随其生产力成比例增长：生产力难以客观量化，薪酬更多受组织预算、岗位定价和个人议价能力影响。
职业与工作方法上首页 5 次 · 2009–2022johndcook.com