利用真实数据剖析“充裕”住房供应的瓶颈
Profiling the "Abundance" housing bottleneck with real data

原始链接: https://laxmena.com/same-capacity-less-throughput

在《丰裕》(*Abundance*)一书中,埃兹拉·克莱因(Ezra Klein)和德里克·汤普森(Derek Thompson)提出,我们之所以无法建造足够的住房、清洁能源设施及研发医疗方案,源于一种“选择性稀缺”——即一系列监管“阀门”的堆积,阻碍了本该高效运转的系统。 作者通过对比奥斯汀和旧金山的住房许可数据验证了这一理论,证实消除监管障碍确实能显著提高产出。然而,当该理论应用于维也纳和伦敦时却出现了偏差。尽管两地的新建速度相当,但维也纳通过建立一套强大的公共与非营利性住房平行系统,成功将租金维持在极低水平。这是一种“绞杀榕”式的策略,即绕过失灵的传统系统另辟蹊径。 结论是,虽然“疏通管道”的论点有其合理性,但这并非唯一的解决方案。作者指出,复杂的社会问题很少能通过单一手段解决。评估未来政策主张的关键在于“先分析,后优化”。在接受一个极具说服力的叙事之前,先进行粗略的数据测算并质疑其适用范围,有助于区分支撑性证据与花言巧语。大多数情况下,简单的核实就能看出拟议的解决方案在数量级上是否对症。

``` Hacker News 最新 | 过往 | 评论 | 提问 | 展示 | 招聘 | 提交 登录 用真实数据剖析“富足”住房瓶颈 (laxmena.com) 6 个积分,由 laxmena 发布于 1 小时前 | 隐藏 | 过往 | 收藏 | 1 条评论 帮助 tptacek 6 分钟前 [–] 这个分析,不管价值如何,都是在和稻草人辩论。Klein 和 Thompson 从未声称“许可改革”是唯一可用的杠杆。Abundance 所记录的住房策略是 YIMBY(“是的,在我家后院”)运动的策略,而 YIMBY 主张的是“全方位”措施。如果能建补贴性住房,就去建;与此同时,修复排他性分区规划,并为市场(我们居住的绝大多数房屋都是由市场建造的)扫清障碍,使其能有效运作。回复 指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系 搜索: ```
相关文章

原文

My book club is reading Abundance by Ezra Klein and Derek Thompson this month. The core idea fits on a napkin, so before the meeting I decided to actually check it against real data. Here's what I found, and where it fell apart.

The idea, in one picture

Same capacity, less throughput

Housing, clean energy, cures for disease. The inputs to all three haven't really moved. Money's there. Technology got cheaper, not more expensive. Roughly the same number of people know how to build this stuff as always did.

What changed is the pipe between the inputs and the output.

Over the decades, every time something went wrong, somebody added a valve. A highway almost bulldozed a neighborhood in the '70s, so now there's a checkpoint for that. An environmental study got added in the '90s. By the 2000s you needed a public comment period too, sometimes more than one. None of these were dumb decisions in isolation. Each solved something real. But stack enough of them and the pipe might as well be shut, even though nothing on the input side changed at all.

Klein and Thompson call this chosen scarcity. Anyone who's inherited a legacy codebase already knows the pattern under a different name: unaddressed technical debt. A pile of individually-reasonable shortcuts, left unrefactored for so long that the system's throughput has almost nothing to do with its actual capacity anymore.

I liked the idea. I also didn't fully trust it. So before the meeting, I ran the numbers.

Test one: does the throughput number actually check out?

Austin vs San Francisco throughput

I compared two U.S. cities that get cited constantly in this debate: Austin, which started clearing its own valves out around 2015, and San Francisco, which mostly didn't.

The gap is not small. Austin permits roughly 18 new homes per 1,000 residents every year. San Francisco permits about 2. Eight times the throughput. Same country. Same everything, really, except the rules.

I ran the actual arithmetic using an elasticity number borrowed from a housing study out of Auckland, New Zealand, where a comparable policy change happened and got carefully measured.

Where the straight-line model breaks

Extrapolated ten years out, Austin's predicted price effect blew past -100 percent, which is obviously impossible. That's useful, actually — it means you can't stretch a small, well-measured experiment out to ten years and still trust the exact number it spits out. Markets saturate. Construction costs and demand put a floor under how far prices can fall, and Austin landed on that curve instead of the dashed line.

San Francisco's model predicted something like an 11 to 19 percent rent decline. Instead, rent there is rising faster than almost anywhere else in the country right now, up nearly 19 percent over the past year. Turns out an AI hiring boom rolled through right when the small supply gains were supposed to show up, and a model that only tracks supply has no way of seeing that coming.

Test two: the case that broke my model completely

Then I checked a pair I expected to tell the same story: Vienna versus London.

Same throughput, wildly different price

Here's where it got weird. Vienna and London build housing at almost the same rate, barely a 20 percent difference. If clearing the pipe were the whole mechanism, their prices should look almost identical.

They don't. Vienna's rent is roughly a third of London's, and has stayed flat for two decades.

Two ways to fix a bottleneck

The reason has nothing to do with permitting speed. Forty-three percent of Vienna's housing stock is public or nonprofit housing, running alongside the private market instead of depending on it to eventually get fixed. It's the housing-policy version of the strangler-fig pattern: instead of refactoring a legacy system riddled with a decade of shortcuts, you stand up a clean system next to it and let it carry the traffic that matters most. Combined with old rent-control rules on the pre-1945 stock, that parallel system is what actually holds prices down. London never built a second pipe. It just kept adding valves to the one it already had.

This matters more than it looks. The book's whole argument is: clear the pipe, let the existing system move faster. Vienna barely touches that lever. It built a second system that doesn't need the first one fixed to work at all. Both approaches raise total output, but only one of them shows up in the book.

What I'm actually taking into the meeting

Profile before you optimize

So what's the actual takeaway here?

Mostly this: the mechanism is real, but only when you can isolate it cleanly. Austin shows that. So does the documented policy change in Auckland and Minneapolis. Clear the pipe, throughput goes up, and prices come down in a way you can actually measure.

But Vienna is the one that's going to stick with me, because it's proof this isn't the only lever available. Anyone telling you a genuinely messy problem has exactly one fix is skipping a step, even when the fix they're describing is real.

And honestly, the habit I want to keep out of all this has less to do with housing than with how I plan to evaluate the next big claim somebody hands me. Profile before you optimize. Don't assume you already know which function is slow, check. Before a compelling story gets to explain what you're seeing, spend two minutes running rough numbers on it yourself. You won't always get proof out of that. But you'll see fast which parts of the argument are load-bearing and which ones just sound right.

Less “was the book correct” and more “what's the cheapest way to check whether a claim is even the right order of magnitude.” Most of the time, that's enough to tell you which parts to trust.

联系我们 contact @ memedata.com