软件产业是世界上最盛产新管理制度的产地。从敏捷开发方法到极限编程到测试驱动开发方法(TDD)，诸如这样的缩写名称和框架还在不断涌现。为什么会这样？
有人说是这个产业还不成熟：软件工业还很年轻，每一次的创新都是向真正真理靠近一步。另外一些人说是因为软件人喜欢整事儿，神经质不能自控。而我要 说的是，如果在这个过程中我们获得了不少可以称之为楷模的成果，那么，同样，诚实的说，我们也造就了不少具有讽刺意味的理论方法，并在很多时候实实在在的 被人使用。
(我相信下面这个列表是很搞笑的，同时也很具有讽刺意味)。
白痴驱动开发方法(ADD)
任何一个开发团队，当他们的所有重大决定都由那个最大的偏执狂决定时，这就形成了白痴驱动开发模式。只要白痴先生在屋内，所有的智慧，逻辑和处理方 法就都会被排挤到窗外，不管是多么的愚蠢、自私的事情，但只要是他想出来的，那就是最好的。虽然有制度和步骤方法，但白痴先生并不理睬，没人去遵守。
认知失调开发方法(CDD)
在一个组织里，有两伙或更多的人，他们对软件应该如何被开发出来的信念有分歧。这些信念分歧造成的紧张局势——体现在每次会议中的斗争，双方阵营中关于个人观点的争辩——最终更大的影响了项目的决定，而对软件的真正信仰却被抛在了脑后。
遮羞布技术方法(CYAE)
所有个人努力的动力都来自确保当灾难发生时自己不受责备。
鸵鸟开发方法(DBD)
每个人都在假装知道有办法能解决目前正在发生的事情，而且事情能一切顺利，但现实情况是，事情一团糟，没有任何措施动作来应对这些问题。而当事情进一步变遭时，会有更多的人变成通过否认事情的真相或把自己隔绝到自己负责的项目中的那一小模块里来聊以自慰。
向上爬方法论(GMPM)
人们写代码、做设计的唯一目的就是增加他们的曝光度、满足老板们的怪念头、加速他们仕途晋升的速度或坐到最豪华的办公室里——不管他们的工作努力方 向离既定的目标相距多远。这包括致使灾难发生来让某人成为英雄，写出短期来看是非常精彩的修改但当人员变更后会导致灾难后果的代码，注重表面工作而忽略实 际价值。
我相信你一定还看到过其它种未提到的工作方法论——说说吧，让大家开开眼界。
[本文英文原文链接：Asshole driven development ]
引用来自“小爱大福”的评论
国内需要制度化规范化软件开发工作流程，只有这样才能跟已经很发达的外企抗衡，一个公司的强大不在于技术团队的技术强大，而在于制度的强大，有不同意见是正常的，有不同意见才能碰撞出不一样的火花，关键是要各自拿出可行方案，通过论证最终达成相互间的妥协，其中最关键的是谁来做裁判！
引用来自“i33”的评论
这嘴型 能吸了玻璃上吧
一经接手终身负责
所有个人努力的动力都来自确保当灾难发生时自己不受责备。