为什么IT行业无法像其他行业一样快速交付大型，无故障的项目？

看完《国家地理》的MegaStructures系列影片后，令我感到惊讶的是大型项目的完成速度如此之快。在纸上完成了初步工作（设计，规格等）后，大型项目的实现本身仅需要数年甚至数月的时间。

例如，空中客车A380 “于2000年12月19日正式发射”，以及“于2005年3月上旬”已经对飞机进行了测试。大型油轮，摩天大楼等也是如此。

将此与软件行业的延迟进行比较，我不禁要问为什么大多数IT项目如此之慢，或更准确地说，如果有足够的人员，为什么它们不能在相同的规模下同样快速，无故障？

诸如空中客车A380之类的项目都具有以下两个特点：

• 重大的不可预见的风险：虽然这不是首架飞机，但它仍然推动了技术的极限，对于小型客机而言，运转良好的事物可能由于物理限制而不适用于大型客机；以同样的方式，使用了尚未使用的新技术，例如，当波音747于1969年制造时，它们就不可用了。

• 总体而言，与人力资源和管理相关的风险：项目中途退出的人们，因休假而无法联系到某个人，常见的人为错误等。

有了这些风险，人们仍然可以在很短的时间内完成像大型客机这样的项目，尽管交付延迟，但这些项目仍然取得了巨大的成功，而且质量很高。

在软件开发方面，这些项目几乎不如客机那么大和复杂（从技术和管理角度而言），而来自现实世界的不可预见的风险则要少一些。

不过，大多数IT项目进展缓慢且迟到，并且向项目中添加更多开发人员并不是解决方案（从十人的开发团队到2000个开发人员的团队有时可以更快地交付项目，有时不能，但是有时只会损害项目，并增加根本无法完成的风险）。

仍交付的那些可能通常包含很多错误，需要连续的服务包和定期更新（想象一下，每周在每架空客A380上两次“安装更新”，以修补原始产品中的错误并防止飞机坠毁）。

如何解释这种差异？是否仅由于软件开发行业还太年轻而无法在一个项目中管理成千上万的人，以便快速交付大规模，几乎无故障的产品？

埃德·尤登（Ed Yourdon）的《死亡进行曲》涉及许多此类元类型问题。

通常，软件行业缺乏以下方面，这阻碍了大型项目的发展。

• 标准化和工作项分解。

  • 当然，这已经变得更好了，但是设计构架仍然无法解决大型系统的问题。在某些方面，软件甚至无法就给定项目的需求达成共识，更不用说将事物分解为组件了。
  • 航空航天，建筑，汽车等都具有非常由组件驱动的架构，具有相当紧密的接口，以允许完全并行的开发。软件仍然允许在相应区域中流血过多。

• 大量成功的类似项目。A380 不是空中客车制造的第一架大型飞机。那里有很多大型软件应用程序，但是它们中的许多在某些方面都遭受了巨大的折磨，并且几乎不可能被称为“成功”。

• 从事过许多相似且成功项目的大量设计师和建造者。与成功的项目问题相关的是，没有人去过那里，因此从可重复性的角度来看，这使事情变得非常困难。

• “从不”建设同一件事两次。在许多方面，一架飞机就像其他飞机一样。它有机翼，引擎，座椅等。大型软件项目很少重复。每个操作系统内核都有很大的不同。查看文件系统中的差异。因此，有多少个真正独特的OS？大对象在某个时候成为基础项目的副本。AIX，Solaris，HP-UX ……预示着AT＆T SystemV。Windows在每次迭代中都产生了令人难以置信的拖累。Linux变体通常都可以回到Linus启动的相同内核。之所以提出它，是因为这些变体的传播速度比真正独特的专有操作系统要快。

• 真正糟糕的项目估算。由于可重复性因子非常低，因此很难预测最终将要达到的大小以及构建所需的时间。鉴于项目经理和管理人员无法动手编写代码并实际看到正在执行的操作，因此会产生对时间表的不切实际的期望。

• 对于大型项目，QA / QC没有得到应有的重视。这可以追溯到组件之间的接口较宽松，并且对组件应如何工作没有严格的规范。这种松散性会带来意想不到的后果，并会滋生错误。

• 持续可衡量的资格。通常，人们会说他们使用X语言或编程工作的年限。时间被用来代替技能或技能。正如之前多次提到的，面试和寻找优秀的编程人才非常困难。问题的一部分是“好”的定义仍然很主观。

我并不是说全部消极，我认为软件行业已经从我们所处的位置取得了长足的进步。这样的论坛和其他论坛确实有助于促进设计原则的对话和讨论。有一些组织致力于标准化软件工程师的“基准”知识。当然还有改进的空间，但我认为该行业在相当短的时间内就取得了长足的进步。

答案是出奇的简单：那些“其他行业” 也有很高的失败率。我们只是在比较错误的事情。编写软件通常被称为“构建”，因此我们将其与其他行业的制造或建造阶段进行比较。但是，如果您看一看，它根本不是建筑：它是设计。软件设计是用代码编写的，构建是由计算机完成的，无论是通过编译软件还是直接对其进行即时解释。

其他行业中的许多设计花费的时间比最初估计的时间更长，花费的成本更高，或者根本就看不到完成。听起来有点熟？

那么，我们在计划软件时正在做什么？好吧，我们仍在设计中，但仍处于早期阶段。

在软件中，没有生产线需要注意。构建最终组件（相对）便宜，并且最终产品的复制既完美又有效，而您可以复制构建工件。

指出一些数字：

1. 开始实施后需求的变化 ; 例如，当第一架空客A380在工厂开始生产时，我不敢相信如果有人想要再增加200个座位，那将被放置在那里。但是即使在程序员开始开发大型软件项目后，仍可以添加5种类型的用户。
2. 复杂性 -大型软件项目极其复杂；可能是人类设计和开发的最复杂的项目；
3. 在体系结构和设计阶段没有花费足够的资源;
4. 领域不成熟 -与其他工程学姊妹相比，软件工程学还相对年轻。这有两个含义：a）启发式方法和良好实践并不多；b）很少有经验丰富的专家；
5. 缺乏数学证明 -在大多数情况下，没有使用数学形式方法来证明某个软件可以按要求工作；而是使用测试。在其他更依赖数学的工程领域中也是如此。其原因在于复杂性；
6. 仓促 -许多管理人员的截止日期无法实现；因此，由于截止日期，代码质量排在第二位。

严格回答这个问题-我倾向于相信其他人对程序员的期望很高（尤其是在交付时间上），并且不完全了解大型软件的编程难度。

问题的前提是有缺陷的。A380和波音787交付都晚了几年。

对于A380而言，大部分延迟是由法国和德国的空中客车公司使用不同且略有不兼容的CATIA设计软件版本引起的。这种不协调表现为线束不太适合飞机。

CATIA没什么问题，CATIA是使用最广泛的飞机设计软件，但是有人在某个地方抛弃了软件配置球。

波音787也遭受了与软件相关的延误，但其大多数问题是更传统的新飞机问题，例如重量控制和供应商交付的不合格零件。

在最初的飞机出现结构问题之后，A380和B787都必须修改机翼设计。

大型复杂项目对所有领域的人来说都是困难的。

摩天大楼的家伙在这里。不知道我是否能回答您的问题，但是我可以肯定地阐明线程中的各个项目。建筑物确实确实发生得非常快。一个主要的限制是语言环境（法规）。但是一般而言，高层建筑从头到尾需要3到10年的时间。

我认为将新建筑与新软件项目进行比较不是很准确。新的建筑物更接近内核或OS的新版本。在这方面，软件开发要快得多。我们永远不会从零开始，因为这将是客户永远不会签约的高风险任务。建筑物中的大多数设计和开发都是经过验证和完成的项目的衍生产品。

从个人经验来看，只有十分之一的项目可以建造。该过程是开发驱动的，而不是设计驱动的，因此，像钢材价格这样的价格在整个项目中上升的那一刻，就是在设计之外，因为设计是该过程的廉价组成部分。

设计需要一个月的时间来完成概念到原理图的工作，花两到六个月的时间进行设计开发，再花六个月的时间来完成详细的设计和施工文档，这些团队由建筑师，规划顾问，结构工程师，风能工程师，服务工程师，数量和成本顾问，测量师，辅助功能工程师，这个清单还在继续...

虚拟与物理的争论不是很准确。我们还主要使用虚拟工具，而且与最终产品相比，我们在时间和规模上都没有影响。在大多数情况下，我们甚至无法以模型规模测试建筑物的各个方面，我们使用模拟来尝试预测可能会发生的情况。

复杂度方面存在差异，但总体而言可能大致相同。我们不仅具有相互联系的单元，而且具有多层抽象和接口的层次，而且人们非常专注于过程的一小部分，这使沟通变得非常困难。

至于设计与开发的论点，我认为这两个过程都是设计构建的。从理论上讲，将它们分隔开听起来很不错，但是如果您不知道如何工作，则无法进行设计。您只会增加失败的风险。

总的来说，根据OP的问题，我的估计（可能是错误的）是编程比工程更像是一门艺术。人们为什么会乐于享受甚至免费享受它，在其中找到表达和优雅？计算机科学也比工程学更像一门科学。您为什么要尝试证明算法，而不仅仅是将现有零件修补在一起并努力使事情正常进行？不知道这是否有意义；我不是软件专家。

关于软件设计和开发的一个方面是媒介本身。计算机使以人为本的工作非常不自然。一切都非常明确，几乎没有公差。很难从思想上解决这个问题，有些人通过在其中转储复杂性来摆脱它。如果没有其他可能与此有关？

那这些设计花了多长时间？年？二？十年？设计是建筑物最复杂的部分，构造本身很容易。

基于本文，人们逐渐理解，软件开发主要是设计过程，其中设计文档是源代码本身。设计过程与生产过程完全不同。它需要经验丰富的人员并且无法计划，因为即使是很小的需求变更也可能导致项目整体架构的巨大变更。这种理解是敏捷方法论的基础，这些方法论着重于提高代码质量（作为最终设计文档），并将测试和调试作为设计过程的一部分，就像他们在风洞中测试飞机模型一样。

构造本身由编译器自动处理。因此，我们能够在数分钟内完成整个产品的生产。

之所以要完成软件项目时要花大量的时间和高昂的成本，是因为管理人员仍然认为他们可以估计，预测和计划这样的设计过程。这种事与愿违的效果往往要多于实际效果。他们仍然认为，通过将人们捆绑到严格的施工过程中，即使最终结果与增加的成本和错过的最后期限大体相反，他们也可以以某种方式提高质量。

想象一下，在空中客车A380的设计过程中，有人在一次会议上插话说：“嘿，能把它做成三翼飞机吗？” 其他人则说：“是的，是三翼飞机。越多的机翼越好。” 接下来的几年是将A380设计变成三翼飞机。在另一次会议上，有人说：“一架三翼飞机？那是旧的。我们想要一架双翼飞机。只需卸下其中一个机翼即可。”

或想像一下，在桥梁建设项目的中间，有人说：“嘿，我们刚与一家船运公司达成了协议。他们需要将桥梁再高40英尺，因为他们的船高得多。请修好。谢谢。 。”

这些只是软件项目（无论大小）以惊人的速度失败的最终原因。

作为具有机械工程背景的IT人员，我经常想知道IT成功率低的原因。

与该线程中的其他线程一样，我也经常将失败归因于IT的不成熟，缺乏详细的标准（是的，我很认真，您是否检查过简单螺栓的标准表？）以及缺乏标准化的原因。组件和模块。

其他行业，例如建筑业或造船业，也有更多的“老路”：特定解决方案原型的知识和经验，以定制的形式反复使用。有没有想过为什么大小和目的不同的建筑物，轮船或飞机看起来如此相似？（当然有例外...）

这是因为这些原型经过了充分的研究，充分的理解，普遍使用并具有可靠的记录。不是因为它无法通过其他任何方式完成。在IT标准化中很少出现这样的情况：（大型）项目倾向于重新发明组件，并同时由同一个人进行研究和交付！

这些不可避免地会导致一次性产品，这些产品的开发和服务成本很高，容易出错，并且在不确定的条件下会以无法预测的方式失败。因此，当然，这些产品被淘汰得更快，被写下并以同样高的成本替换为仅略好一些的产品。IT所需要的等同于工业革命，这场革命将中年工匠变成了高效的工厂。

也就是说，有一些因素使IT真正具有独特性。与其他提到的行业相反，IT确实无处不在：它被用于我们现代生活的各个方面。因此，这是一个很小的奇迹，IT取得了如此巨大的进步，并且能够交付其所做的结果。

恐怕我不同意你的说法。

空客和波音是制造飞机的公司的两个例子。那里有几家制造飞机的公司？如果将它与有多少公司构建软件进行比较，则很少。

拧紧飞机项目和拧紧软件项目一样容易。如果仅飞机制造行业的进入门槛与软件行业一样低，那么您肯定会看到许多失败的飞机项目。

看车；有一些高质量的制造商制造非常耐用和高度先进的汽车（例如路虎，梅赛德斯），而有些制造商则不需要维修一年就可以使用（起亚或奇瑞）。这是一个进入壁垒稍低的行业的完美例子，如果您开始拥有较弱的参与者。

软件没有什么不同。您有很多有问题的产品，另一方面，Windows，Office，Linux，Chrome或Google搜索是非常高质量的项目，它们按时交付，并且质量水平与飞机相似。

许多人想念的另一点是，维护汽车，油轮或飞机是我们生活中需要付出的维护费用。每架飞机在起飞前都必须经过技术检查。您必须每隔几千英里对汽车进行一次检查，并定期更换润滑油，更换轮胎。

软件也需要。如果只有人们像在机械/物理产品上那样花大量的时间在诊断，预防或审核软件的状态和质量上，那么我期望这样的陈述会更少。在启动应用程序之前，您是否每次都阅读应用程序的日志？好吧..如果这是一架飞机，你将不得不;-)

数字构造块可以为1或0。两者之间没有任何关系。

机械设计具有一定的收费标准。我可以在桥中放入一个不完美的铆钉，并且它很可能不会掉下来，但是，即使在代码中，即使只是将0放置在应为1的实例中，也可能会使整个程序失败。

由于计算的逻辑性和交互性，任何很小的变化都可能导致严重的故障。

我经常想知道同一件事。当然（有时）感觉像我们是一群业余爱好者，他们不知道我们在做什么。我不喜欢将责任归咎于经理或其他外部因素的解释-开发人员应对我们创建的内容负责。

我认为我们所从事的业务中错误很少发生。与重建摩天大楼或召回每部售出的手机相比，修补软件价格便宜。

这创造了一种文化，在这种文化中，虫子已成为日常生活的一部分。他们耸耸肩接受了。虽然有些错误可能是不可避免的，但它们是否应该主导我们的日常工作？我完全理解那些不认为质量检查值得麻烦的管理人员，这恰恰是因为他们仍然期待错误。我不理解那些不竭尽全力来生成无错误代码的程序员，因为更正错误很无聊。

本质上，我认为这是一个文化问题，我希望它会改变。

IT（作为独立行业）的工程标准和实践与航空航天有很大不同。考虑到IT专业人员在航空航天业中遇到有关IT的标准文档时的反应，这可能最容易理解。例如，“ 联合打击战斗机C ++”标准最近在互联网上流行。

许多人表示困惑或渴望辞职（希望我们能这样做）；许多人对此表示嘲笑，声称没有以这种方式交付消费产品的实际方法。考虑到不是消费者的期望，而是管理层的期望，这甚至可能是正确的。对于仅编码和编写几个星期而不进行任何演示的编码人员来说，存在很大的不信任感。上帝帮助只设计了两个星期的编码员。飞机并非如此。

在软件方面，人们真的希望现在有一些东西。当然，推理会花一点时间才能真正确定。但是我们一周不能用简单的术语描述一些复杂的事情吗？人们还了解到，用诚实，复杂的术语描述的复杂事物很少激发想象力。因此，许多工程师最终陷入了一个想象中的世界，即以创新的方式将真正简单的事物组合在一起（而不是一个很难完成的世界）。

我的一些东西：

1-标准和零件：它们是飞机制造商，而不是开发商。我不确定，但是我猜想很多零件都外包了。他们没有建立自己的电子/仪器，他们从某家公司获得席位，引擎可能在其他地方开发，等等。

另一方面，软件项目几乎总是从头开始，只有一些小框架/帮助程序到位。

2-上市时间：对于飞机而言，时间并不是关键问题。我敢打赌，空中客车的设计在完成之前就已经确定下来了，他们的确选择忽略了那时可能发生的任何重大突破。（例如，与汽车制造商相同，他们目前开发的尖端技术将在5到10年内问世。）

对于软件，您需要非常敏捷，如果我现在开始一个庞大的项目并花三年的时间来进行开发，而无需进行任何更改，那么我依靠不再可用的技术或我的产品已经完全过时的机会非常高。这又带来了很多问题。

3-发布周期和版本。-飞机“释放”时需要完全完成。没有稳定的Beta版本，每晚构建或类似版本。此外，一旦完成，就只能以较小的方式进行修改。您不能在现有的波音飞机上增加100个座位的附加级别，这是不可能的。

另一方面，软件具有增量更改，这些更改通常只是“有效的构建”，而不一定是最终产品。另外，在IT部门中常说“嘿，让我们在飞机上再增加一个可容纳50吨重的行李箱”。

我认为答案很简单：

1）物理构造和实施的历史可以追溯到人们已经存在了很长时间-我们已经有数千年的时间来开发用于实施物理项目的方法和技术。需要完全不同的新技能的软件“构建”已经有50多年的历史了-我们还没有足够的时间来解决这个问题。

2）虚拟构造更困难-您必须“看”头脑中没有物理现实的事物。它要求您分析和抽象很多信息，甚至不知道您的产品应该是什么样子以及创建产品所要采取的步骤。建造桥梁或建筑物时并非如此。

3）查找软件故障或错误的来源通常比进行物理工程时要困难得多。如果大梁弯曲，您会看到它在哪里弯曲，并且看到支撑它的地方并发生故障，等等。发现软件缺陷可能需要检查大量代码和相互作用的过程-困难，耗时且不受约束物理结构中的物理和数学定律。

我将尝试使用Jack Ganssle嵌入式缪斯作品的逐字逐字回答。尽管到处都显示固件，但是只要用软件替换即可。

比什么？

固件是宇宙中最昂贵的东西。洛克希德·马丁公司前首席执行官诺曼·奥古斯丁（Norman Augustine）在他的精彩著作《奥古斯丁定律》中讲述了国防界遇到的一个问题的故事。高性能战斗机是冲突需求之间的微妙平衡：燃油范围与性能。速度与重量。似乎到了70年代后期，战斗机的重量已经达到了以往的水平。总是追求更大利润的承包商，徒劳地寻找可以增加很多成本的东西，但是却没有任何价值。

答案：固件。无限成本，零质量。航空电子设备现在占战斗机成本的一半以上。当您考虑到最新的美国战机F-22花费10亿美元的流行价格的三分之一时，这是一个很大的变化。奥古斯丁讲这个故事时，几乎高兴不已。

但是，为什么软件如此昂贵？汤姆·德马科（Tom DeMarco）曾经用以下三个词回答了这个问题：与什么相比？他继续讨论相对无聊的商业案例，但是多年来，这个答案在我的脑海中回荡。比起什么？借助软件，我们通常会创建前所未有的复杂性的产品行为。当然，代码很昂贵。但是，在文明史上，从来没有人建造过如此复杂的东西。

考虑以下气泡排序，该气泡排序是从Wikipedia毫不客气地提出来的，并且没有检查其准确性：

void bubblesort(int * A, int n){

    for(int i(0); i < n; ++i)

        for(int j(0); j < n - i - 1; ++j)

            if(A[j] > A[j + 1])

                std::swap(A[j], A[j + 1]);

}

它只有110个非空格字符，也许在一两个小时内就消失了。假设我们没有软件，而不得不使用其他策略来实现某种排序。要花多少钱？

机械工程师可能会吹嘘他的专业比计算机早建立了分类器。考虑IBM 1949年的82型卡分类器（http://www.columbia.edu/acis/history/sorter.html），每分钟可处理650张卡，即使在4 MHz的频率下，我们的代码段也无法管理Z80。当然，模型82一次只能排序一张卡片；完全分类一个牌组可能需要数十次通过。

设计和建造这种野兽花了多长时间？几年，毫无疑问。与我们的代码相比，它的功能显得苍白无比，因为我们的代码要快得多并且可以处理巨大的数据集。但是那是1949年。要用电子元件构建气泡排序需要多长时间-如果没有FPGA和VHDL或CPU？

在一个小时内，我处理了一个粗略的框图，该框图高于芯片级别（块的名称类似“加法器”，“ 16位锁存器”等）。但是排序逻辑显然很混乱，因此我假设只是在某个时候编写适当的方程式并不困难。而且，是的，也许这打破了不可编程的逻辑规则，但是在合理的时间内使用门设计和调试所有这些逻辑的可能性不大。

假设有16位字和地址，该电路将需要大约12个16位锁存器，加法器等。加上内存。而且我不知道未排序的数据如何到达RAM或如何导出结果。这些是未指定的设计要求。纯软件解决方案仅通过编写函数原型即可解决这些需求。

将粗略的框图转换为原理图可能需要一天的时间。然后是时候设计和生产PCB，订购和装载零件（并更改设计以应对意外但不可避免的寿命终止问题），然后使电路正常工作。我们可能要花费数周的时间，并花费大量金钱来购买电路板，零件和适当的测试设备。

所有这些替换了7行代码。很少有真正的嵌入式程序少于10,000个。许多超过一百万。要替换一个真实的超大型计算机程序，需要多少硬件和多少工程设计？

考虑一个像电子表格这样的真实程序。没有处理器，制作一个电路需要多少电路？它可能是一个城市的大小。

固件是宇宙中最昂贵的东西，但这仅仅是因为它解决的问题难以想象的复杂性。但这比任何替代方法都便宜得多。因此，当老板烦躁地问为什么软件要花这么长时间时，您知道该说些什么。 比起什么？

在那里！软件/固件具有无与伦比的复杂性。

软件工程和管理与许多其他工程领域在根本上是不同的。可交付成果不是物理的，生产过程是设计和开发过程。创建软件的另一个副本的边际成本基本上为零。所有成本都在开发第一份副本中找到。

由于将软件工程和管理作为一门学科还比较年轻，因此仍然存在一些错误信息和虚假事实（请参阅本参考资料），这实际上阻碍了软件开发和工程。

并非所有开发人员都是平等创建的。有些不错，有些则不好。

尝试一直阅读别人的代码，以了解我的意思。过多的逻辑语句可能会增加风险。这些风险可能导致不良行为或错误。没有足够的逻辑语句，现在您具有空引用。优秀的程序员了解这一点，并且知道何时何地做什么。但是没有人是完美的。事情很复杂。加上其他人考虑周全的工作，就很容易看出项目是如何运作的。

大教堂过去需要长达100年的建造时间。

某些空中客车飞机需要一百万行代码才能工作。

您花在改进上的时间越长，您得到的改进就越多，因此请给软件行业几个世纪的尝试错误才能使它变得更好，并且我们将看到开发一个没有错误的可靠的大型项目需要多少时间。或缺陷。

大型项目通常发生在大型组织中。如果您从未在大型组织中工作过，那肯定会影响到绩效和生产力，这就是官僚主义。

令人惊讶的是，许多人不知道什么是官僚主义（通常与政治混淆），甚至不知道何时/何时出现官僚主义问题。

我们最近结束了一个实施智能卡身份验证的项目。最初估计为三个月。花了15个月。延迟没有任何成本，预算，范围或技术原因。范围实际上很窄-仅适用于特权较高的帐户（管理员帐户），总共约1200个帐户。

另一个重要因素是您的业务伙伴。这将包括供应商。如果您的合作伙伴遇到了导致项目延迟的问题，那么没有什么方法可以真正解决延迟问题。他们不能直接为您服务，您可能无法向合伙人开除那个人，这可能是原因。合作伙伴可以被解雇，也可以受到经济处罚或激励措施的约束，但这并不能改变项目延迟的事实。这正是波音公司采用波音787梦想飞机的猛烈采购战略时发生的情况。

我为您提供了一个简短的版本：

不管是容易做的还是精简的，我们都写一个程序来代替它。

然后与元流程进行斗争。

本身并不是那么真实，但是每天都会建立成千上万个博客，而不是编写博客引擎。每个工作日，都会编写数千个Excel宏，而不是为它们编写专门设计的数据库应用程序。

还有很多其他因素-这里提到了其中一些-但我想在讨论中加入这一点。

缺乏责任感...当飞机坠毁时，人们被起诉。软件行业对任何软件缺陷不承担任何责任，因此缺乏创建健壮和安全产品的动机。

大多数大型项目的子项目具有高度的可分离性，您可以在其中定义少量设计约束。当这些子项目各自完成时，整个项目将起作用。如果子项目出了问题，那么整个工作就不会有任何问题。您只是在寻找替代方法来完成子项目（例如，使用其他引擎）。

在软件项目中，无论是从实践上还是从人性的角度来看，这都是可能的，但困难。

在某种程度上，其他行业已经学会了这种分离性是一件好事的艰难方法。例如，如果您要使用劳斯莱斯飞机发动机，则无需使用仅适用于具有特定设计的机翼的特殊劳斯莱斯螺栓和固定点，然后尝试切换到普拉特和惠特尼，您必须从头开始重新设计整个机翼（这反过来又需要对机身进行彻底的重新设计，进而需要您购买不同的座椅，进而需要您购买不同的机上娱乐系统，哪一个...）。可能存在一些联系-您不能不加照顾就交换引擎-但将此类事情降至最低时，大型项目通常会更好地工作。

我假设，将大型软件项目设计为相互之间具有清晰接口的小型软件项目的集群，只要大型项目实际上由小型项目的集群解决，就不会经常失败。（在这方面可能会犯错误。）

构建软件系统与构建物理结构非常不同。也就是说，实现有很大不同。例如，建造一艘大型油轮时，您会执行许多相对简单（虽然不容易！）的任务，例如通过机器人或用手将零件焊接在一起，拧紧所有螺母和螺栓，上漆，然后通过全部搬入进行装饰。设备和家具等。确实，所有这些都是非常简单的事情。

但是，在软件方面，它变得更加复杂。例如，您如何精确地实现产品的安全登录和用户凭证存储部分？您可以使用哪些库和工具？您熟悉哪些库和工具？您如何精确地编写哈希+盐析函数，如何确保它的安全性？您可以通过多种方式执行此操作，因此无法为此类事情设置任何实际的实用设计模式。是的，上述设计模式确实以“最佳实践”的形式存在于较小的规模，但是每个软件系统都与其他软件系统非常不同，并且该领域的发展和变化是如此之快，以至于根本无法跟上。

盖房子时，您并没有真正遇到这样的问题，即您意识到主要的支撑墙似乎不足，需要更换，需要拆除到目前为止的进度，并通过重做支撑墙从基础开始。您可以在设计阶段解决此类问题，因为预测建筑物所需的支撑墙相对简单。

但是，软件不是这种情况。您不能真正将整个产品设计为单个实体然后实施。软件设计过程通常是迭代的，目标和需求会随着产品的实施和测试而改变。整个软件开发是一个反复的过程，在此过程中，事情通常会在最不期望的情况下发生变化，并且很多时候这种变化会带来挑战，这些挑战需要更多的工作，更多的复杂性以及不幸的是，最终要花费更多的金钱，时间和艰苦的工作才能正确。

因此，从本质上讲，难以交付大型项目以及估计项目时间表和路线图的原因是软件开发，尤其是工作设计是非常复杂的领域。复杂性是根本问题。

“大型项目”的定义是不正确的。

从技术上讲，大型项目可以按时交付，并且可以完美无误地进行，因为它是多年来构建的许多次的东西。

• 吃豆人克隆。
• 一个计算器
• 文字编辑器

我确信您在想……”但是那些都是小项目！文本编辑器很简单。” 我不同意你的看法。计算机异常复杂。有时仅在操作系统上安装和设置用户可能会很困难，而且您甚至都没有编写操作系统或构建硬件。

您正在谈论的项目是大型项目，类似于太空探索。您怎么知道发展银河系之间的旅行需要多长时间？我们基于什么模型？您拥有已知的已知信息，已知的未知信息，未知的已知信息，最后还有未知的未知信息，它们在软件开发中经常会出现。

我认为这个问题是我们的期望之一。仅仅因为技术已经存在并不意味着使用它会在一段时间内成功（或明智地使用）。如果其他行业表现得像软件行业一样，那么到本世纪末，我们将有黑洞驱动的真空吸尘器出售。或某些“有远见的人”将拥有建立月球基地的资源，并决定星巴克将真正为游客“丰富”体验。我认为问题不在于软件行业，而在于对它的期望。

尽管这并不是唯一可以提及的事情，但我认为有一个基本的事情值得指出。大多数产品旨在适应现有行为。即使是突破性的产品（例如汽车），通常也可以适应现有的行为，并且只需简单一点/更轻松/更便宜/任何方式即可。是的，通常对现有行为也有一些副作用（例如，为汽车提供燃料而不是为马提供食物），但是后者的大多数往往是一个相当小的副作用。

相比之下，几乎所有不会改变用户行为的软件（例如，让他们更轻松地完成工作）基本上都从第一天起就保证完全失败。更糟糕的是，大型软件项目并不仅仅是涉及用户在单个级别上的行为，但涉及大集团的行为-通常是整个组织的行为。

简而言之，设计软件本身通常是工作中最容易的部分。困难的部分是重新设计人民的工作。很难开始。以一种不仅会起作用，而且会被接受的方式进行操作，要困难得多。

就像您提到的那样，空中客车A380并不是一个成功的项目。我碰巧在一家CAD / CAM公司工作，有人告诉我（我们也有空中客车公司）被推迟了几年，因为他们在不同公司使用了不同版本的软件。也就是说，在世界的不同部分设计了不同的部分。并且在集成时，他们知道所有设计都无法集成，因此他们必须在一个版本中重新设计。因此，我认为它并不成功。如果它发生在2-3年之前，那将是空中客车公司的游戏规则改变者。

另外，关于健壮的软件，您会发现任何飞机，汽车（ABS，EPS，气候控制等）或航天飞机上都有超过50％的软件正在运行，并且让我相信它们非常健壮。仅仅是我们更加接近软件，并且有更多的软件程序，因此我们看到了更多的错误。

请访问：http : //www.globalprojectstrategy.com/lessons/case.php?id=23 并查看空客A380取得了多少成功。

这里的软件工程师具有工程学背景，并有一名建筑工人。我们已经就工作的差异进行了长时间的讨论（和争论）。

软件工程是关于设计新事物的。几乎所有基本内容都在某个地方的开源库中完成。在雇用软件工程师的几乎所有工作中，她都必须设计一些不存在的东西。

在诸如建筑和大多数工程形式的项目中，本来应该放在软件的“库”中的事物已经被充分设计。要建塔吗？只需复制并粘贴现有结构中的计划，并进行一些修改即可。

实际上，我决定不成为工程师的主要原因之一是，您将大部分时间花在对现有发明进行10％的改进上，而同时又可以用来对诸如社交网络之类的内容进行编程。

工程学中的新设计并不多；一个非常熟练的工程师是可以将现有设计改造成新的东西或对其进行改进的人。但是，几乎每个程序员都希望修改设计，修改设计或创建新的东西。

回顾一下标准已经完全改变了多少，从汇编到C再到C ++再到Java，JavaScript，C＃，PHP等。10或20年前没有多少代码可以回收。这与说的很不一样...汽车或航空业可以从几十年前开始不断改进设计。

在软件方面，项目管理非常困难。时间估算最好由工作人员完成，但是当他们忙于估算时，他们并没有在编写代码。这诱使人们完全避免进行任何项目管理。

通常，许多代码取决于特定人员，如果这些人员迟到或无法执行，则代码不会继续前进。相反，如果您想制造汽车，则只需雇用不同的人来组装轮胎，底盘，电池，发动机等。面向对象的框架和现有的框架使之成为可能，但是当您从头开始设计所有内容时，这可能不切实际。

软件可能会允许失败。测试可能会很昂贵。在软件中，当您仅能解决崩溃问题时，很想跳过所有测试。在大多数工程形式中，“崩溃”可能是致命的。

您确实有使用广泛测试的编程方法，例如极限编程（实际上已在软件大型项目中使用）。但是，由于期限紧迫（可以故意加紧设置），因此很容易跳过所有编程并启动带有错误的程序。从长远来看，乔尔·斯波尔斯基（Joel Spolsky）风格的“始终修复所有错误”将节省更多时间，但是不纪律的人将跳过此操作并失败。

小项目更好。我妻子曾经要求我在一家大公司找到工作。最后，有人争论说大公司是坏公司……对她来说，大公司有很多资源，经验，功能项目管理和正确的程序。对我而言，大公司就是恐龙，您的大部分时间都花在固定代码，测试代码和文档上。

我已经看到少于10人参与了数百万美元的IT项目。更多的人会放慢该项目的进度，并增加不必要的官僚主义。WhatsApp是价值数十亿美元的“小型”项目的一个示例。不是说不可能进行大型项目，而是您根本不需要成千上万的人来生产价值数十亿美元的软件。

在其他问题中并未真正解决的一个原因是，软件领域的创新速度在基于材料的世界中很少发生。

原因之一是软件演进是一个积极的反馈周期，因为软件（编程语言，构建工具，IDE）用于构建软件。这是雷·库兹韦尔（Ray Kurzweil）的加速收益定律的最明显例子，它以指数级的速度增长。一旦掌握了一个框架，编程语言和通信协议，就可以继续学习下一个了。

如果飞机是像软件一样建造的，我们将每隔一个模型就更换材料，每18个月将其容量和速度提高一倍，用刚发明的东西替换每个新模型的发动机技术，同时增加游泳和搜索外星人的能力生活。

哦，理想的情况是，一旦您的工作结束，它就可以收听语音指令，并且可以兼作完全身临其境的电影院，彩弹射击场和带深色房间的夜总会。一样的东西！（该公司制造的飞机可以可靠地将您从A转移到B，在拥有电影院，彩弹射击和夜总会功能的飞机问世一年后，这家公司破产了。）

对我来说，软件工程面临的主要问题是用例，用户和跨平台。

用例

一架飞机有多少个用例？大多数只是从一个地方飞到另一个地方。也许还有更多诸如雷达，交通控制等功能，但用例很明确，而且用处不大。在软件工程中，我们面临着不清楚的要求和不知道自己想要什么的用户。不同的用户需要不同的配置/流程，是否可以根据用户的需求定制飞机（我想拥有电视和冰箱！）？

用户

谁经营飞机？飞行员，副驾驶员，一些管家（如果算在内）和塔楼操作员。他们都是专业人士，工作描述也很清楚。菜鸟和假人都使用该软件，更不用说邪恶的黑客和破解者了，同时仍然需要与其他模块（例如OpenID或Google AdSense）集成。如果一架飞机仍然可以由假人驾驶，但仍能幸免于导弹或忍者劫匪的袭击，那么您可以说飞机具有与软件相同的质量。

跨平台

一架飞机只在地球的天空中飞行。我不确定他们如何处理大雾，大风或炎热，寒冷和潮湿的气候，但是飞机的设计并非以不同的重力水平飞行（如果能飞向火星，我会感到惊讶）。有时，应用程序必须在不同的平台上生存，例如Internet Explorer，Google Chrome，Firefox和Safari浏览器（抱歉，Opera）或Safari或Windows XP / 7/8，Windows OS级别的Linux。更不用说移动设备和不同的分辨率和方向。

如果您认为其他行业可以顺利完成项目，则应阅读有关1977年建造的花旗集团中心大楼的故事。即使经过近7年的规划和建设，该大楼的设计仍存在严重缺陷，可能会导致建筑物倒塌。预计每16年发生一次风暴事件。

换句话说，花旗银行中心每年都会站台倒塌的可能性是16分之一。

最初的设计师没有意识到这些问题，但幸运的是，一位研究该建筑物的学生抓住了它。

一切似乎都很好，直到LeMessurier告诉他，他才接到电话。根据LeMessurier的说法，1978年，一名建筑系本科生与他联系，对LeMessurier的建筑物提出了大胆的主张：花旗银行中心可能会随风飘扬。

实际上，维修是在夜幕降临时进行的，涉及最少的人员来维护设计缺陷的保密性。

已为建筑物周围的10个街区半径制定了紧急疏散计划。

他们整夜焊接，并在黎明时退出，就像大楼里的居民重新上班一样。

直到作家乔·莫根斯特恩（Joe Morgenstern）听到一个聚会上的故事并采访了LeMessurier之前，这个故事一直是个秘密。莫根斯特恩（Morgenstern）在1995年的《纽约客》上打破了这个故事。

这就提出了一个问题；未经公众认可，秘密修复或忽略了项目中还有多少致命的设计缺陷。

• 设计缺陷几乎摧毁了纽约的摩天大楼（slate.com）
• 花旗集团中心（wikipedia.com）