编程与软件工程blog.plover.com
我做过的最烂的项目
The shittiest project I ever worked on (2013)
2013 — 2019，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
作者 Mark Jason Dominus 回顾自己做过的最糟糕项目：为 Prudential 开发一个 affiliate locator 应用，过程充满混乱需求、无效沟通和过度工程，最终交付物几乎无人使用。事后看，客户真正需要的可能只是一个告诉访客打电话的静态 HTML 页面。
为什么经久不衰：它把大组织软件项目里需求失真、过度工程和“交付即成功”的荒诞讲得既好笑又精准，因此十几年后仍被开发者反复引用。
HN 评论精选
大公司软件项目低效，可能因为软件并非其核心业务，应关注商业逻辑而非开发者视角。
关注 HN 和类似开发文化久了，我越来越感到矛盾：一方面大公司被描绘成内部政治盛行、经理不懂开发、浪费大量金钱的无能巨兽；另一方面它们又极其富有和成功。也许对非技术公司来说，软件本身只是花生米，精力更该放在谈推荐费之类的业务上，所以细节上随便评论是因为他们（正确地）不在乎。也可能只是一种局部最优：你不需要无浪费地产出开发者眼中的“好东西”，因为你的目标公司也同样低效。重要的是别只停留在“哈哈傻经理”，背后有更深的原因。
bonoboTP查看英文原文
Having followed HN and similar dev culture (Dilbert etc.) for some time now, I feel a growing contradiction that I cannot fully resolve. On the one hand big corporations are presented as these incompetent behemoths that are locked in their internal petty office politics, managers are clueless as to what is being or should be developed, and tons of money is wasted, they are wooed by empty marketing etc. On the other hand these organizations are immensely wealthy and successful. It may actually be that they are right, and for non-tech-centered companies this whole software stuff is really peanuts and their mental energy is better spent on other business-related stuff. So they will come up with random low-effort comments on all sorts of details because ultimately they (rightly) don't care. What actually matters is to negotiate deals like referral fees, or coming up with other contract ideas that will bring a lot of revenue in. Or maybe it's just an equilibrium, a local optimum. You don't have to produce "good" stuff (in the developer's sense) without waste, precisely because the other company that you're targeting is also inefficient in similar ways. I'm really not sure but I think it's important to look beyond just "haha, stupid managers, they can't make up their mind". There must be deeper reasons.
咨询项目的成功标准常是客户满意并付款，而非产品被真正使用；交付物可能沦为高层 PPT 素材。
任何为大组织做过咨询的人大概都有这种故事。如果最终客户满意并付了钱，基本就该算成功。我曾为美国一家大型金融机构花六个月做单页应用；交付时结果比最初提案稀释太多，我本可以拿设计师六个月的截图放进 PPT 说“完成了”——因为公司那位 VP 最后就是这么做的，只不过用的是我们做的、除他之外没人用过的网页截图。好处是我和那位 VP 成了好朋友，项目也付掉了我第一套房相当一部分房贷。
bshimmin查看英文原文
I think anyone who has done any consulting with a big organisation probably has one of these stories. As one of the other commenters says, if the end result is something that the client is happy with, and they actually pay you, you should basically consider this a success! I spent six months building a single-page app (back when that was still an exciting sounding thing) for a major US financial institution; by the time we actually delivered it, the result was so watered down from the initial proposal that I could've just taken some screenshots from what my designer had produced six months earlier and put them in a PowerPoint deck and said "Done!" - because this was, in fact, what the VP at the company ended up doing, except they were screenshots from the web app we built that no one other than the VP himself ever used. On the plus side, I became good friends with the VP and the project paid off a significant chunk of the mortgage on my first house.
失败根源是需求分析和利益相关者沟通不足；“快速简单”的项目往往没人真正想清楚。
虽然读起来有趣，但这是没做尽职调查就一头扎进编码的经典例子。我刚入行时，最常毁掉项目的就是没理解用户需求。他们永远不会告诉你想要什么，只会在你交付后告诉你不要什么。经验丰富的开发或业务分析师能坐下来和利益相关者在纸上构建系统，顺着图逐个处理问题；最终得到的是明示需求（冰山一角）和未明示假设（冰山）。这类项目很容易识别，因为它们常被叫作“快速”或“简单”，在外行话里意思是还没人真正想过。
redact207查看英文原文
Although it's a fun read, it's a classic example of diving into coding without giving a project it's due diligence. There's nothing that's derailed my projects more consistently when I started out as not understanding the user's needs. They'll never tell you what they want, only what they don't want after you deliver something. I think that's the key difference to an experienced dev/BA. One who can actually sit with the stakeholders and build the system on paper and go through each of the problems as the diagrams connect. What you end up with is the stated requirements (tip) and the unstated assumptions (iceberg). These types of projects are easily spotted as they're often called "quick" or "easy", which in layman's means no one's really thought about it yet.
介绍作者及其经典 Perl 著作，说明作者在编程社区的地位。
可能有人不知道文章作者：他叫 Mark Jason Dominus，写过最精彩的编程书之一《Higher Order Perl》，可以免费下载。读它会看到许多在大型企业工作中遇不到的编程技术洞见，也会让你更欣赏 Perl，理解它为何能成为解决各种问题的绝佳选择。
kamaal查看英文原文
For those who don't know about the author of this post. His name is Mark Jason Dominus, the author of one the most awesome programming book that one can ever read. Higher Order Perl, is available for free download. If you read it you will see some amazing insights into programming techniques most people would have never heard of encountered in MegaCorp jobs. You will also grow a great appreciation for Perl in general and understand how it can be an amazing language of choice for a wide variety of problems.
历次讨论
同类还值得读
开源应用架构
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编辑精选