创业与商业danluu.com编辑精选
这家公司为什么这么大？我周末就能做出来
Why's that company so big? I could do that in a weekend
2016 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇 Dan Luu 的文章围绕“这有什么难，我周末就能做出来”展开，说明产品看似简单，背后常有规模、实时性、可靠性、计费、硬件/网络和法规等大量隐藏工作。文章也把问题引向公司规模：必要复杂度与组织臃肿需要分开判断。
为什么经久不衰：它把“周末就能做”的错觉拆成可检验的工程细节，同时不放过“大公司是否真的需要这么多人”的反问，因此多年后仍适合任何产品/团队规模讨论。
HN 评论精选
Uber 的例子说明“只是打车应用”背后是实时规模、计费和调度等大量隐藏工作。
我常听缺乏经验的工程师这么说，我的回答是：那你为什么不做？最近一位初级工程师这样评价 Uber，他的逻辑是“它只是个打车应用”。可 Uber 之前和之后都有很多打车应用，却没有一个成为 Uber。中等复杂度的 CRUD 应用当然能做接单和调度，给 App 返回 JSON；但如果有 10 万行程同时进行、要追踪位置并在地图上渲染，还要实时绕开拥堵、完整计费、按供需动态调价、持续 A/B 测试、处理不断变化的地图，这些才让 Uber 成为 Uber。还觉得周末能做完吗？
malux85查看英文原文
I often hear this logic from inexperienced engineers. My answer to them is: Then why don't you do it? <grin> Recently a junior engineer said this to me about Uber, and I helped him to understand - His logic was "it's just a taxi app". There were loads of Taxi apps before Uber and loads of them after Uber. Yet none of them were uber? Sure that a medium complexity CRUD app can do the pickup and scheduling, and spit out some json to the app. But what if you have 100,000 journeys taking place simultaneously, and you must track their positions so that you can render the journey map on the invoice? Can you do live traffic planning and re-route around the busy traffic on the fly? Does your weekend include the full billing system? This is a mandatory requirement for a business. Can you spot busy periods and increase the fares according to the laws of supply and demand? All online in realtime? Can you continuously A/B test this to optimise profits? Can you deal with the fact that maps and roads are always changing? All of these and more are the things that make Uber, Uber, otherwise you're just one of those shitty taxi apps that failed. Still think you can build it in a weekend?
报站系统看似简单，实际牵涉硬件、网络、GPS、法规和本地化，足以变成团队一年的工程。
最近讨论公交车内报站系统有多难，听起来像周末项目？再想：硬件要抗柴油发动机振动；要有 3G/4G 连接和本地 ISP 数据合同；软件要处理断网；GPS 要在信号差的大城市判断当前停靠站；绕路跳站要能检测并报下一站；机场巴士要双语；要兼容助听器；服务器要知道所有站点和不同站点类型；要同时支持年度时刻表和实时更新；因政府补贴要输出开放数据 JSON/XML 并发布到开放数据服务器；因欧盟赞助，控制界面还要翻译成德/法/英/西语。于是周末项目变成 10 个工程师做一年。
systemtest查看英文原文
I recently had a discussion about how hard it would be to have a system inside a bus to announce the next stop. Sounds like a weekend project right? Think a bit further: - Hardware needs to be resistant to harsh diesel engine vibrations - 3G/4G connectivity - Need a mobile data contract with local ISP - Software needs to be able to handle network disconnections - GPS needs to be able to pin-point at which stop the bus is currently stopped, even with bad GPS coverage in larger cities - If the bus skips a stop because of a detour, the software should be able to detect it and announce the next stop - The announcement should be bi-lingual for Airport busses - The announcement should work for people with hearing aids - Server needs to know all bus-stops - Server needs to know different stop types, such as bus terminals, intersection stops, regular stops, hand-over stops, virtual stops - Server needs to be able both work of a yearly bus schedule and real-time update - Server needs to output in an understandable JSON/XML because the government subsidies demand an open-data format - Server needs to publish data to an open-data server because of the subsidies - Because the bus-company is sponsored by European Union money the control interface should be translated to German/French/English/Spanish And now this weekend project takes a team of 10 engineers working for a year.
真正该问的是公司离最优人数有多远；经验上更常见的是臃肿，而非数百人被高效利用。
这是稻草人式的对话。“我周末能建”就推断公司低效当然是谬误，但这不是有意思的辩论。更好的问题是：给定业务/产品，持续高效交付价值大概需要多少工程师？公司离这个最优数有多远？这很难量化，反事实太多，只能靠经验判断哪种更可能：(1) 资金充足的产品团队真能高效利用数百人，还是 (2) 不能。我在内部见过一些 (2)，从没见过 (1)，所以更倾向于相信公司不必要地大。让我惊讶的是本线程不是这样倾向——有人真见过 (1) 吗？我没见过鬼，所以不信鬼。
wellpast查看英文原文
This is such a straw man conversation. Of course it is a fallacy to think "I could build that in weekend" and translate that to a claim about the inefficiency of a company. I think that's what is being responded to in this thread. But that's not the interesting debate. A better consideration (imho) is this: For a given business/offering/product, what is a likely optimal number of engineers needed to continuously deliver the product's value efficiently? Then: How far is a given company from that optimal number? This is a hard analysis to do. It is virtually impossible to quantify or put this kind of evaluation in a laboratory. There are too many counterfactuals that would be at play. We really just have to consult our experience and consider which of these is the more probable: (1) A business/offering/product team with lots of money is really good at utilizing its hundreds of staff. OR (2) It's not. I've seen a few (2)s from the inside. I have never seen a (1). Therefore I lean more probabilistically toward the belief that a company is needlessly big. What surprises me is that that's not where people on this thread are leaning---but has anyone on this thread actually ever seen a (1)??? If not, where is this belief coming from? I've never seen a ghost, so I don't believe in ghosts....
有时周末原型确实能完成，但组织臃肿和政治会抵制这种演示，也说明不值得留在那种组织。
我完全同意，但只到某个程度。有时极复杂的东西看起来简单，是因为聪明人做出了优雅方案，路人就以为自己能复现。可我工作过的公司有一整队工程师和 QA 花几个月做基本是 Django CMS 的东西，还大量“非我发明”地从零写一切。我厌倦后，周末在家用 Django 实现完。但我学到两个教训：其他利益相关者很不喜欢有人展示他们数月没做成的可用原型，我因扰乱流程被狠狠训斥；我也真的不想待在这种组织，换到更小更灵活的公司后快乐多了。
kstrauser查看英文原文
I wholeheartedly agree, to a point. Sometimes hideously complex things look so easy because really smart people came up with a particularly elegant solution, so any rando off the street sees it and figures they could reproduce the thing. However, I worked for a company who had a whole team of engineers and QA people working for months on what was basically a Django CMS, but with a large dose of "not invented here"-driven writing of everything from scratch. I'd finally gotten tired of it, so I spent a weekend at home implementing it in Django and being done with it. I did learn two very important lessons, though: - The other stakeholders really did not like someone demonstrating a working prototype of something they'd been doing unsuccessfully for months, and I got a thorough chewing out for disrupting their processes. - I really didn't want to work for such an organization, and was much happier after moving to a smaller, more nimble company.
历次讨论
同类还值得读
微软已死（2007）
Microsoft is Dead (2007)
Paul Graham 2007 年的一篇短文，判断微软在互联网与创业竞争中已不再令人畏惧、失去影响力——所谓“死”并非字面倒闭。
创业与商业上首页 8 次 · 2007–2025paulgraham.comH&R Block 与 Intuit 游说反对简化报税（2017）
H&R Block and Intuit Lobbying Against Simpler Tax Filing (2017)
2017年ProPublica调查报道梳理了H&R Block和Intuit如何通过游说反对更简单的美国报税方式，尤其是政府预填税表和免费申报等改革。
创业与商业上首页 5 次 · 2017–2022propublica.org你本不该有老板
You Weren't Meant to Have a Boss (2008)
Paul Graham 2008 年的经典文章，论证人类在演化中习惯于小团体协作，而大公司的层级结构和老板制度是人为产物，对程序员尤其有害——因为编程的本质是创造新事物，而大公司…
创业与商业上首页 5 次 · 2008–2020paulgraham.com为什么要在经济糟糕时创业
Why to Start a Startup in a Bad Economy
Paul Graham 的经典短文，论证经济衰退并不是创业的障碍：真正决定成败的是创始人和产品，而非宏观环境；衰退期反而竞争更少、人才更易招、成本更低。
创业与商业上首页 5 次 · 2008–2022paulgraham.com做那些不可规模化的事
Do Things that Don't Scale
Paul Graham 2013 年的经典创业文章《Do Things that Don't Scale》。
创业与商业上首页 4 次 · 2013–2025paulgraham.com编辑精选