（译者注：原文这里是视频，请自行观看，本文不再网页呈现。视频地址：http://www.youtube.com/embed/BV7a4rufMOg）
本文介绍了如何hack流行游戏Flappy Bird【注1】。虽然该游戏已经从Google Play和App Store下架了，仍然阻止不了人们为网络创造非常好的复制品。人们也催生了该游戏的一些有意思的参数：“Flappy Bird Typing Tutor”和“Flappy Math Saga”。
...无论大小项目，大型团队还是我个人，陈腐的联邦机构还是牛逼的硅谷公司，我都工作过。我学习并使用过至少20种编程语言。我还经历过瀑布模型/预先设计模型（BDUF：big design up front），结构化编程，自顶向下，自下向顶，模块化设计，组件，敏捷，Scrum，极限，TDD，OOP，快速原型，RAD，还有我可能想不起来的其它方法。我不敢肯定它们都管用。
【EDIT：让我解释一下本文的目的。我认为它们本身不能提供一个可预期的或可复制的软件开发过程。我不认为使用一种方法论会使项目失败。大多数软件开发方法论试图使编程成为类似工程的过程，在那方面它们是不足的。】
一种方法论是否管用取决于条件：团队生产力，快乐，保持，遵从，可预言，有责任，沟通，每天代码行数，人月，代码质量，工件等。如果你用对了地方，每个方法论都管用。但是依照唯一的衡量方法就会出现问题，那就是按时、不超过预算地满足需求，我还没有看到任何方法论能够取得一致的结果。
我自己的经历有些轶事，但是它们也被我认识的每个程序员分享。这表明轶事是每个人都有的：软件开发方法论的严格学习并不管用，因为控制所有变数是不可能的。
做个思想上的实验：假定两组程序员小组，相同的需求、日程规划和预算，同样的环境，相同的语言和开发工具。一个小组使用瀑布模型/BDUF，另一个使用敏捷技巧。很明显这不是一个好的实验：个人技能和团队成员性格，彼此如何沟通，都将对方法论产生非常大的影响。
Alistair Cockburn 2003年的论文《软件开发中的人和方法论》指出，“人们的状态，因人不同，一个时刻与另一个时刻也不同，形成了团队行为和结果的第一位的驱动力。他们彼此相处如何，性格与工作分工是否匹配等因素，都对方法论产生着巨大的、与项目相关的约束。结果表明了通常人们的性格特点对方法论有一定影响。”
当我在1970年开始编程时，软件开发稍稍通过项目经理、业务分析员和高级程序员等层级管理。我们没有选择语言和工具。我在公司里的一些大型的、复杂的项目就是这样做的。一些成功了，一些没有成功。现在让程序员选择方法论和工作方式，还有语言和工具比较普遍了。分析员不再出现在大多数程序员的经历里，项目经理已经被演变成“team lead”和“Scrum master”，没有管理授权，除了团队一直通过的仪式，并不真正控制什么。
严格的管理，像甘特图、日程规划和文档，被精简为“利益相关者”和“用户”，再被抽象为“用户故事（user...
[caption id=”attachment_272” align=”alignnone” width=”350”]
One of those days?[/caption]
我经常发现我着迷于现代技术。我的意思是，我们经历了计算机从像建筑物大小 发展到 相等计算能力的、小到能放进口袋。50年（我让你决定，对于我们大部分人使用计算机看猫的照片、在网上沟通，是不是会感到悲哀）。这是一个印象深刻的壮举，特别在考虑到地理名词在50年里几乎没有什么变化。
然而，最常让我着迷的是人们以及他们与新技术互动（和创造！！）。我沉浸在开发文化里，开始一次又一次地看到相同的模式，试着了解是什么让一些项目（尤其是人们彼此隔离地工作方式）不能得到发展，又是什么让一些项目如此成功。因此今天我想写一个故事来描述这一点，在我看来，开发者生产效率的巨大杀手。