失败的软件开发思想或技术的一个很好的例子是什么？

具体来说，是什么地方群众的观念错了的例子。人们为什么首先要抓住想法？为什么这些想法被驳回了？或者这些想法仍然存在并且很好，如果是，为什么呢？

例如，我可能将CORBA（和其他类似技术）描述为试图解决软件组件之间的通信问题的事物。许多人认为有必要在各个组成部分之间定义合同。最终，HTTP + JSON为大众解决了这个问题，其他各种RPC机制（例如Thrift和Proto-bufs）也出现了。

基本上，就像在计算机之外的世界中一样，思想和技术在争夺注意力，发挥杠杆作用等。而且有些人似乎是赢家已有一段时间了，但随着《下一件大事》的出现，它逐渐变得晦涩难懂。它可能与或没有任何关系，实际上是更好的选择。见证VHS与Betamax，还是各种DVD格式之间的较近战争。

CORBA庞大，笨拙且难以使用，但它是当时某些人可以发明的最好的东西（请注意，它是在万维网-和HTTP，Java，XML等广为人知之前设计的）。而且这也是委员会设计的经典示例，他们在每个想法中都塞满了每个人的想法，以使每个人都满意，最终使它无用地（肿（至少在今天看来是这样）。更不用说它的价格了，随着FOSS的出现，价格很快就变得过高了。

最终，HTTP + JSON为大众解决了这个问题

至少对于没有看到过类似的“最终解决方案”的人最终会跌倒……最好记住，在那时，人们对CORBA也有类似的看法；-)

我觉得很容易引用CORBA的兴衰：

CORBA的历史是计算机行业已经见过很多次的历史，而且当前的中间件工作，特别是Web服务，似乎将重现类似的历史。[...]

总体而言，OMG的技术采用过程必须被视为CORBA下降的主要原因。该过程鼓励委员会和政治操纵进行设计，以至于很难实现技术平庸，更不用说技术卓越了。此外，不连续的特征的添加导致建筑视觉的逐渐侵蚀。[...]

像OMG这样的民主程序特别不适用于创建好的软件。尽管存在已知的程序问题，但是该行业还是更愿意依靠大型财团来生产技术。Web服务是当前中间件的灵丹妙药，其使用的流程与OMG十分相似，并且从很多方面来看，它也受到内f，支离破碎，缺乏架构一致性，委员会设计和功能膨胀的困扰。Web服务似乎不可避免地会颁布与CORBA十分相似的历史。

现在从另一个角度来看：在阅读您的“群众思想”一词时，我想到的事情与CORBA或其他标准大不相同。这些通常是一个人或一小组的想法。我想到了臭名昭著的做法/观点，例如“牛仔编码”，“编码和祈祷”，“在我的机器上工作”等。这些都是恕我直言的真正“群众思想”，因为这几乎是任何初学者的方法开发人员本能地开始编写代码。而且它们是错误的，因为它们既不会在空间上也不会在时间上扩展-人们无法以这种方式创建大型的，可维护的，可扩展的程序。然而，我感到遗憾的是，人们尝试在世界各地的专业商店中使用这种方式仍然是一种规范，而不是例外。

另一个极端是许多经理和理论家对软件开发“正确方法”的想法，这些想法体现在诸如CMM，RUP，Waterfall等大M方法中。所有这些方法背后的想法是，您所需要的只是正确的流程，它将开始以确定性的方式自动生产高质量的软件，无论开发人员实际是谁。注意，同样的游戏也可以使用敏捷方法来玩-只是标签的改变。任何经理认为选择（并保留）其开发团队的正确成员比开发过程的重要性要小，无论发生什么过程，都注定会失败。但是，这种对过程的信念似乎仍然很普遍-也许仍在管理学院教授？

常见的人为失误的例子是瀑布模型。这是定型瀑布模型的图，该模型也出现在Winston Royce的论文“管理大型软件系统的开发”中。

该图像后跟以下文本：

我相信这个概念，但是上述实现方式存在风险，并且会导致失败...在开发周期结束时进行的测试阶段是第一个事件，其时序，存储，输入/输出，传输等是有别于分析的经验。这些现象无法精确分析。例如，它们不是标准的数学物理偏微分方程的解。但是，如果这些现象不能满足各种外部约束，则始终需要进行重大的重新设计。一个简单的八进制补丁或某些孤立代码的重做将无法解决这些困难。所需的设计更改可能会造成很大的破坏，以致违反了设计所基于的软件要求，并为所有内容提供了依据。要么必须修改要求，要么需要对设计进行重大更改。实际上，开发过程已回到原点，人们可以预期进度和/或成本超支多达100％。

在本文的稍后部分，Royce提出了替代的过程模型，其中涉及在当前阶段和上一个阶段之间进行迭代，以及在需求分析设计与设计代码测试之间的另一个循环。他还确定了许多文档以及在哪些阶段应完成这些文档，并主张客户参与以及每个阶段中的多个瀑布，以包括分析，测试和使用所有涉及的工件。实际上，Royce讨论的内容可能被认为是敏捷方法的早期方法-尽管仍然非常受计划驱动，但它是敏捷运动的基础。

我不知道为什么人们会停在第一个瀑布上。我想他们喜欢冒险和失败。

从更高的抽象级别自动生成代码，或者自动编程。

维基百科的文章在某种程度上缺乏历史信息，但是自从程序员比计算机变得昂贵以来，这一直是管理者的梦想。

在开发了诸如Fortran和Cobol之类的高级语言之后，出现了针对特殊领域的语言（如报告编写）的开发。 Easytrieve和SAS是两个示例。

在1980年代的CASE工具中风靡一时。CASE代表计算机辅助软件工程。人们认为，严格应用工程原理将使软件开发更快。这些工具没能赶上的主要原因，除了费用外，还在于工具有效运行所需的高水平数据标准化。

互联网在1990年代崭露头角。Internet促进的编程类型激增。程序员需要以很少见的方法，以前所未有的速度处理插图，地图，照片和其他图像以及简单的动画。生产这些物体的技术数量成倍增加。自动编程的梦想消失了。

将编程外包到较便宜的位置是减少程序员成本的剩余方法之一。外包的问题包括通信问题和规格问题。

正式方法

曾几何时，有人提出可以证明软件是正确的。（这种想法是，测试不能表明没有错误，但可以证明。）不幸的是，为程序设计证明有一些主要缺点：

• 比编写程序要困难和耗时。
• 它必须覆盖整个程序，这意味着您需要任何库，操作系统等的证明。
• 不能证明没有错误，因为这些错误可能是偶然引起的。

这个概念在70年代非常流行。

链接：http : //en.wikipedia.org/wiki/Formal_methods http://c2.com/cgi/wiki?ProofOfCorrectness http://c2.com/cgi/wiki?PractitionersRejectFormalMethods