编程与软件工程moishelettvin.blogspot.com
Windows 关机功能的烂摊子（2006）
The Windows Shutdown crapfest (2006)
2010 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是微软前员工 Moishe Lettvin 的博客文章，讲述他在 Windows Vista 开发期间参与“关机菜单”设计的亲身经历：一个看似简单的功能，因为八个团队、层层管理和冗长的决策流程，最终耗时极长且效果糟糕。文章成为对大公司官僚化开发流程的经典批判，多年来反复引发讨论。
为什么经久不衰：它以一个具体小功能为切口，生动揭示了大组织协作失灵的普遍问题，至今仍是讨论工程文化、决策机制时被反复引用的案例。
HN 评论精选
微软从专家决策转向数据决策，是因为专家决策导致声誉恐惧和口才决定结果
我在 Vista 时期加入微软，此后一直（有时是间接地）参与 Windows 相关工作。这只是我的个人看法，但看到决策方式的演变很有意思。如果概括这种变化，我会说它从基于专家意见的体系演变成了基于数据的体系。之所以每次规划会议都有八个人在场，是因为他们的专家意见是决策的主要依据。除了决策质量差之外，这还带来两个非常负面的后果：1）声誉被激烈争夺。个人担心一旦出错，声誉受损会限制他们影响未来决策的能力，最终导致职业生涯的死亡。无论这是否真的发生，这种恐惧本身就导致了过度的谨慎和对共识的盲目追求。2）在缺乏数据的情况下，一个能言善辩的谈判者往往能获得自己想要的结果，无论这个结果多么不理想。如今数据被用得多了，也就是遥测。我理解遥测仍然是个敏感话题，但基于专家意见的决策……
bradford查看英文原文
I started at MS during Vista and I've been involved (sometimes tangentially) with Windows ever since. This is all my opinion, but It's been very interesting seeing the decision making process change over time. If I had to summarize the change, I'd say that it's evolved from an expertise-based system to a data based system. The reason why eight people were present at every planning meeting is because their expert opinion was the primary tool used in decision making. In addition to poor decisions, this had two very negative outcomes: 1) reputation was fiercely fought for. Individuals feared that if they were ever incorrect, the damage to their reputation would limit their ability to impact future decisions and eventually lead to career death. Whether this actually happened or not is irrelevant; the fear itself caused overt caution and consensus seeking. 2) In the absence of data, an eloquent negotiator is often able to obtain their desired outcome, no matter how sub-optimal that outcome might be. Nowadays, I see data used a lot more, hence the telemetry. A while ago, in response to criticism of Windows telemetry habits, I wrote: "Telemetry is, by now, a fundamental part of the engineering process. Products that don't incorporate it are going to be clobbered by products that do. Microsoft didn't start this paradigm, but I think they had to incorporate it in order to stay competitive." I understand that telemetry is still a delicate issue, but the expertise based decision making of yester-year truly sucked for many, and I don't see a viable alternative.
亲历者佐证：微软庞大的团队和流程最终产出的成果小得可笑
我对此深有体会。这在微软是普遍现象。我们团队负责 Bing 和 Facebook 的初期整合，有约 24 个专职人员（还包括几位总监级经理！）。我们被认为是“敏捷”的，因为大约每 4 个月发布一次功能（那大概是 2009 年）。后来我们在 Facebook 和扎克伯格及其团队搞了一次黑客马拉松，之前是经理们层层冗余的讲话，说这是最重要的整合项目。猜猜 4 个月后发布了什么？Bing 首页上的一个“赞”按钮！而且组件代码还是从 Facebook 开发者门户直接拿的。
theoutlander查看英文原文
I can relate to this. It was a common theme across Microsoft. In one instance, the team I was part of was responsible for the initial integration of Bing and Facebook. We had about 24 dedicated people on the team (a few partner/principal group managers too!). Our team was considered agile because we released most features every 4 months (this was around 2009 I think)!!! Anyway, we had a hackathon at Facebook with Zuckerberg and the FB team. There were all these big (redundant) talks by every manager up that chain about how this is the most important integration, etc. Guess what came out 4 months later??? A like button on the Bing home page! The kicker was that the code for the widget was picked from the facebook developers portal.
过度抽象和“防呆”式架构是性能灾难的根源
（引用同作者后来的博文）我在负责提升 Outlook 98 性能的团队。Outlook 97 发布后，我的主管把启动时的每一个函数调用都打印出来，足有一英尺高的一摞纸。他花了一周用荧光笔逐行找他所谓的“蠢东西”，结果找到一大堆。这些大多不是某个程序员的愚蠢决定造成的，而是源于一种架构和心态——试图通过把内存管理等“危险”的东西过度抽象来防止开发者伤到自己。 needless abstraction 会狠狠咬你一口。我和主管花了几个月清理代码，去掉隐藏实际行为的代码，让代码更贴近机器、更明确、更紧凑、更少泛化。
feelin_googley查看英文原文
"I was on the team responsible for improving performance for Outlook 98. Right after Outlook 97 shipped, my lead printed out every single function call made when Outlook started up. It was a stack of paper about a foot high. He spent about a week going through this printout with a highlighter, looking for "stupid shit", as he called it. Turned out, there was plenty of it. It further turned out that most of this "stupid shit" wasn't a result of any one programmer making a dumb decision; most of it was a result of an architecture and a mindset which tried to prevent developers from shooting themselves in the foot by gratuitously abstracting away "dangerous" things like memory management. Again: needless abstraction will bite you in the ass if you're not careful. My lead and I spent months going through the Outlook code exorcising "stupid shit" -- removing code which hid what it was actually doing, getting the code cleaner and closer to the machine, making everything more explicit, tighter, and less generic." The above is excerpted from a later blog post by the same author.
Joel 当年的“再见按钮”设想后来在 iPhone/iPad 上成为现实
对于没点对链接链的人，这是原文回应的 Joel 的文章。让我印象深刻的是这是 2006 年写的。Joel 建议的“再见按钮”实际上就是后来 iPhone 和 iPad 上的方案（少了用户切换）：用户不再需要关心那些不同的状态，要么短暂离开，要么长时间离开并让硬件关机。
MBCook查看英文原文
For those who didn’t click through the right chain of links, here’s the original article this one was respond to. I do wonder what they were trying to do that didn’t happen though. https://www.joelonsoftware.com/2006/11/21/choices-headaches/ The thing that stood out to me is this is from 2006. Joel‘s suggestion of the “b’bye button“ is effectively what we got on the iPhone and later the iPad (minus user switching). The user no longer has to care about all those different states. They can either go away for a little while, or go away for a long while and have the hardware turn off.
历次讨论
同类还值得读
开源应用架构
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编辑精选