如果建筑师必须像程序员那样工作（1995）
一篇 1995 年的幽默文章设想建筑师在软件行业条件下工作，引发了对现代技术项目如何运作的更广泛批评：需求模糊且不断变化、时间表不切实际、流程繁重，以及“有责任却没权力”。评论者将软件与施工及其他工程领域比较，争论编程是否应该更像受监管、承担责任的物理设计，还是它的可变性本就合理地带来迭代混乱。许多人将失灵归咎于企业激励、MBA 文化和照搬教条的“敏捷”，而另一些人则指出，客户、糟糕的规格和政治约束在各行各业中都普遍存在。
对这篇讽刺的整体反应
- 许多人认为这篇文章对现代软件工作痛苦地准确，尤其是在需求模糊、需求不断变化和任意约束方面。
- 也有人认为这只是被夸大的“程序员受害者心态”，忽略了其他项目制领域中同样存在的失灵。
- 还有几位指出，文章显然是在搞笑，但之所以引起共鸣，是因为它反映了行业中常见的病态。
与现实中的施工和建筑的相似之处
- 有施工/建筑经验的人报告称，实际情况惊人地相似：犹豫不决或爱显摆的客户、最后一刻的改动、不切实际的想法（例如在很晚阶段才加上屋顶泳池或平台泳池），以及不完整或错误的规格说明。
- 高端住宅和“富客户”项目据说非常像这篇讽刺：不断重设计、来自杂志的潮流，以及异想天开的结构要求。
- 也有人强调差异：建筑师和工程师面临严格监管、个人法律责任、安全顾虑，以及更慢、更昂贵的变更周期。
软件开发中的关键痛点
- 在不确定性下做估算：简短的规格说明、被迫把工作原子化成“点数”，以及无论估算是否准确都会受到惩罚。
- “有责任却没权力”：为那些你既不能也无法修复的问题背锅。
- 持续打断：突发事件、上下文切换，以及不会相应调整截止日期的强制状态会议。
- “企业版敏捷”广受批评，被认为充满仪式感、微观管理严重，并且脱离了敏捷最初的理念。
经理、PM 和客户的角色
- 有人认为优秀的产品/项目经理应该替工程师挡住混乱的客户；也有人说 PM 往往会变成另一种混乱和微观管理的来源。
- 对开发者是否应直接与客户交流存在分歧：有些人认为这对理解问题至关重要；另一些人则警告这会带来承诺过度和预期管理问题。
关于类比的争论：软件 vs 物理工程
- 一方认为：施工和软件本质不同（比特 vs 砖块、可逆性、反馈速度、角色碎片化），因此这种类比是“错误的”。
- 另一方认为：类比仍然有用，可以揭示某些软件期望映射到物理领域时有多么离谱。
更广泛的组织/管理批评
- 一些评论把责任归咎于“MBA 化”、表格驱动的决策、季度导向，以及与工作本身脱节的职业经理人。
- 另一些人指出，几乎所有大型组织都存在失灵，无论是在软件还是传统工程领域。