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

#1 楼

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

通常，软件行业缺少很多以下内容，它们妨碍了大型项目。



标准化和工作项分解。


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


大量成功的类似项目。 A380不是空中客车制造的第一架大型飞机。有很多大型软件应用程序，但是其中许多软件在某些方面都遭受了巨大的折磨，并且几乎不可能被称为“成功”。
有大量的设计师和建造者拥有在许多类似且成功的项目中工作。与成功的项目问题相关的是，没有人来过那里，从可重复性的角度来看，这使事情变得非常困难。
“从不”建设同一件事两次。在许多方面，一架飞机就像其他飞机一样。它有机翼，引擎，座椅等。大型软件项目很少重复。每个操作系统内核都有很大的不同。查看文件系统中的差异。因此，有多少个真正独特的OS？大对象在某个时候成为基础项目的副本。 AIX，Solaris，HP-UX等……预示着AT＆T SystemV。Windows在每次迭代中都产生了令人难以置信的拖累。 Linux变体通常都可以回到Linus启动的相同内核。之所以提出它，是因为这些变体的传播速度往往比真正独特的专有操作系统要快。
项目评估确实很糟糕。由于可重复性因子非常低，因此很难预测最终将要达到的大小以及构建所需的时间。鉴于项目经理和管理层无法掌握代码并实际看到正在执行的操作，因此就产生了对时间表的不切实际的期望。
QA / QC并没有像以前那样被强调得那么大。项目。这可以追溯到组件之间的接口较松散，并且对组件应如何工作没有严格的规范。这种松散性会导致意想不到的后果，并且会滋生错误。
持续可测量的资格。通常，人们会说他们使用X语言或编程工作的年限。时间被用来代替技能或技能。正如之前多次提到的那样，面试和寻找优秀的编程人才非常困难。问题的部分原因是“好”的定义仍然很主观。

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

#2 楼

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

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

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

#3 楼

要指出一些数字：开始实施后需求的变化；例如，当第一架空客A380开始在工厂生产时，我不敢相信如果有人想要再增加200个座位，那将被放置在那里。但是即使在程序员开始开发大型软件项目后，也可以添加5种类型的用户。

复杂性-大型软件项目非常复杂；可能是人类设计和开发的最复杂的项目；
在架构和设计阶段没有花费足够的资源；

领域不成熟-软件工程与其他工程姐妹；这有两个含义：
a）启发式方法和良好实践不多；
b）经验不足的专家不多；案例中没有使用数学形式方法来证明某个软件可以按要求工作；而是使用测试。在其他更依赖数学的工程领域中也是如此。原因很复杂；

匆忙-许多管理人员的截止日期无法实现；因此，由于截止日期，所以代码质量排在第二位。大型软件编程有多困难。

#4 楼

问题的前提是有缺陷的。 A380和波音787交付都晚了数年。 。这种不协调表现为线束不太适合飞机。

CATIA没什么问题，CATIA是使用最广泛的飞机设计软件，但有人在某个地方丢下了软件配置球。与软件有关的延误，但其大多数问题是较传统的新飞机问题，例如重量控制和供应商交付的不合格零件。

A380和B787都必须在初始飞机之后修改机翼设计有结构性问题。

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

#5 楼

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

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

从个人经验来看，只有十分之一的项目得以建造。该过程是开发驱动的，而不是设计驱动的，所以在整个项目中，像钢材价格上涨之类的时刻就在设计之外，因为设计是该过程的廉价组件。

设计工作需要一个月的时间来完成原理图的设计，花两到六个月的时间进行设计开发，再花六个月的时间来完成详细的设计和施工文件，这些团队由建筑师，规划顾问，结构工程师，风能工程师，服务工程师，数量和成本顾问，测量师，可访问性工程师以及清单不胜枚举...

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

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

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

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

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

#6 楼

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

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

构造本身由编译器自动处理。因此，我们能够在短短几分钟内完成整个产品的开发。计划这样的设计过程。这种事与愿违的效果往往要多于实际效果。他们仍然认为，通过将人们捆绑到严格的施工过程中，即使最终结果与成本增加和错过了最后期限大相径庭，他们也可以以某种方式提高质量。

#7 楼

想象一下，在空中客车A380的设计过程中，有人在一次会议上吹嘘说：“嘿，能把它做成三翼飞机吗？”其他人则说：“是的，是三翼飞机。越多的机翼越好。”接下来的几年是将A380设计变成三翼飞机。在另一次会议上，有人说：“一架三翼飞机？那是旧的。我们想要一架双翼飞机。只需要拆下其中一个机翼。” “嘿，我们刚与一家船运公司达成了协议。他们需要将桥梁再高40英尺，因为他们的船高得多。请修理。谢谢。”

这些只是其中的一部分软件项目（无论大小）以失败率惊人地失败的原因。

评论

---

这正是发生的情况。管理类型或客户每隔10秒就会改变主意，这只会使开发人员感到沮丧。我因为这样的废话辞职了

– Erin Drummond
2012年12月17日上午9:45

---

想到这一点：youtube.com/watch?v=BKorP55Aqvg&feature=kp

– miraculixx
2014年6月9日17:21

---

#8 楼

作为具有机械工程背景的IT人员，我经常想知道IT成功率低的原因。
作为该线程中的其他人，我也经常将失败归因于IT的不成熟，缺乏详细的标准（是的，我很认真，您是否检查过简单螺栓的标准表？）以及缺乏标准化的组件和模块。

其他行业，像建筑物建造或造船业一样，还有更多的“破败之路”：特定解决方案原型的知识和经验，以定制的形式反复使用。有没有想过为什么大小和目的不同的建筑物，轮船或飞机看起来如此相似？ （当然还有例外情况。不是因为它无法通过其他任何方式完成。在IT标准化中，这种情况很少发生：（大型）项目倾向于重新发明组件，并在同一时间由同一个人进行研究和交付！它们的开发和维护成本很高，容易出错，并且在不确定的条件下会以无法预测的方式失败。因此，当然，这些产品会更快地过时，被写下并以同样高的成本替换为稍好一些的产品。 IT所需要的等同于工业革命，工业革命将中年工匠变成了高效的工厂。

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

评论

---

+1。标准化的好例子（简单螺栓的标准图纸）。在IT中，很少有标准化的组件。以注册表单为例：每个网站都在重塑自己的注册表单，很少有开发人员知道其注册表单如何使用unicode，空白字符串，字符串太长等来表现。

– Arseni Mourzenko
2012年7月29日23:20

---

@MainMa：不好的例子，您是否从div中创建按钮，文本框，选项框，选项框？不，您可以重用浏览器的表单元素；浏览器使用了操作系统的表单元素。

– Lie Ryan
2012年7月30日15:31

---

我只是在谈论内部而不是控件。采取一些随机的网站。可以使用中文字符作为密码吗？您可以使用25个字符的密码吗？如果在密码或用户名中添加空格，会发生什么？所有这些都可以归一化，但事实并非如此，每个人都在为每个项目重新发明轮子，这通常很糟糕，即没有哈希和/或加盐或密码限制为16个字符（例如：MSN）等。

– Arseni Mourzenko
2012年7月30日15:49

---

将IT从“工匠”更改为“工厂”可能是不可能的。工厂正在执行一个已经创建的过程。工厂的工人很少或没有人的思想来执行他们的过程。由于这个事实，许多工厂都用机器人代替了人。在软件中，您不是在执行过程，而是在创建过程。创建软件更像是设计工厂及其过程，而不是运行工厂。尽管软件创建可以从标准中受益，但它不能从根本上成为工厂。

–mike30
2012年8月1日19:19

---

@ArseniMourzenko，将“螺栓数据表”（即工具，设备）与“注册表格标准”进行比较是一个糟糕的比较。注册表更像是“屋顶”或“前门”（实际上，有无数种方法可以制作这些）。螺栓比较起来更像是处理器流水线行为。它离我们所需要的还很遥远：可靠的操作系统（具有严格定义的特性，而不是“数据可能会根据所使用的安装选项而进入磁盘”）和同上开发工具（它们需要能够检查90％的代码是否为标准）属性）

–sehe
17-10-7在23:10

---

#9 楼

恐怕我不同意您的发言。

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

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

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

软件也是如此。您有许多错误的产品，另一方面，Windows，Office，Linux，Chrome或Google搜索是非常高质量的项目，它们按时交付，并且质量水平与飞机相似。

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

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

#10 楼

数字积木可以是1或0。两者之间没有任何关系。

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

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

#11 楼

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

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

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

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

#12 楼

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

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

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

#13 楼

我的一些东西：

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

另一方面，软件项目几乎总是从零开始一些小型框架/帮助器。

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

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

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

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

#14 楼

我认为答案很简单：

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

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

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

#15 楼

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


与什么相比？洛克希德·马丁公司前首席执行官诺曼·奥古斯丁（诺曼·奥古斯丁）在他的精彩著作《奥古斯丁定律》（Augustine Laws）中，讲述了一个有关国防界遇到的问题的生动故事。高性能战斗机是需求冲突的微妙平衡
：燃料射程与性能。速度与重量。
似乎到了70年代后期，战斗机的重量已经达到了以前的
。承包商一直追求更大的利润，却徒劳地寻找可以增加很多成本但又没有负担的东西。


答案：固件。无限成本，零质量。航空电子设备现在占战斗机成本的一半以上。当您考虑最新的美国战机F-22花费10亿英镑的惊人价格三分之一时，这是一个很大的变化。奥古斯丁（Augustine）讲这个故事时，他几乎高兴不已。汤姆·德马科（Tom DeMarco）曾经用以下三个词回答了这个问题：与什么相比？他继续
讨论相对无聊的商业案例，但是多年来我一直在脑海里回荡那个答案。比起什么？使用软件，我们
例行地创建前所未有的复杂性的产品行为。当然，
代码很昂贵。但是，在文明史上，从来没有人造出过如此复杂的东西。

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位锁存器”等）。但是
排序逻辑显然很混乱，因此我只是扔进了PLD中，
假设在某个时候写适当的方程式并不难。而且，是的，这可能打破了
no-programmable-logic规则，但是使用门在任何合理的时间内设计和调试所有逻辑
的可能性不大。 -gallon gas。

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

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

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

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

固件是宇宙中最昂贵的东西，但这仅仅是因为它解决了难以想象的复杂性。但这比任何其他产品便宜得多。因此，当您的老板烦恼地问
为什么软件要花这么长时间时，您知道该说些什么。
与什么相比？


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

#16 楼

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

由于相对较年轻的软件工程和管理学科而言，仍然存在一些错误信息和虚假事实（请参阅本参考资料），这从整体上阻碍了软件开发和工程。

#17 楼

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

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

#18 楼

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

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

您花费越多的时间进行改进，就越您可以获得改进，因此请给软件行业几个世纪的尝试错误以使其变得更好，我们将看到开发一个没有错误或缺陷的坚实的大型项目需要花费多少。

#19 楼

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

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

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

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

#20 楼

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

不管是什么容易做的事情，或者精简的东西，我们都写一个程序代替它来做。 -process代替。

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

还有很多其他因素-其中一些在这里提到-但我想补充一点进行讨论。

#21 楼

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

#22 楼

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

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

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

#23 楼

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

但是，当涉及到软件时，它变得更加复杂。例如，您如何精确地实现产品的安全登录和用户凭证存储部分？您可以使用哪些库和工具？您熟悉哪些库和工具？您如何精确地编写哈希+盐析函数，如何确保它的安全性？您可以通过多种方式执行此操作，从而无法为此类事情设置任何实际的实用设计模式。是的，上述设计模式确实作为“最佳实践”以较小的规模存在，但是每个软件系统都与其他软件系统大不相同，并且该领域的发展和变化是如此之快，以至于根本无法跟上。 />
盖房子时，您并没有真正遇到这样的问题，即您意识到主要的支撑墙似乎不足，需要更换，需要您拆除迄今为止的进度并从通过重做支撑墙作为基础。您可以在设计阶段解决此类问题，因为预测建筑物所需的支撑墙相对简单。

但是，软件不是这种情况。您不能真正将整个产品设计为单个实体然后实施。软件设计过程通常是迭代的，目标和需求会随着产品的实施和测试而改变。整个软件开发是一个反复的过程，在此过程中，事情通常会在最不期望的情况下发生变化，而许多次此类变化会带来挑战，需要更多的工作，更多的复杂性和不幸的是，最终要花费更多的金钱，时间和艰苦的工作才能正确。 >
因此，从本质上讲，难以交付大型项目以及估算项目时间表和路线图的原因在于软件开发，尤其是工作设计是非常复杂的领域。复杂性是根本问题。

#24 楼

一个大型项目在技术上可以按时交付，并且可以完美无瑕地进行，因为多年来已经进行了许多次。
/>

吃豆人克隆。
计算器
文本编辑器

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

您要谈论的项目是巨大的项目，类似于太空探索。您怎么知道发展银河系之间的旅行需要多长时间？我们基于什么模型？您有已知的已知，已知的未知，未知的未知，最后还有未知的未知，它们在软件开发中碰巧会遇到很多问题。

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

#25 楼

尽管这并不是唯一可以提及的事情，但我认为值得指出的一件基本事情。大多数产品旨在适应现有行为。即使是突破性的产品（例如汽车），通常也可以适应现有的行为，并使其变得更简单/更容易/更便宜/更容易做到。是的，通常也会对现有行为产生一些副作用（例如，为汽车提供燃料而不是为马匹提供食物），但是后者的大多数往往只是一个很小的副作用。 >相比之下，几乎所有不会改变用户行为的软件（例如，让他们更轻松地完成工作）从第一天开始就基本上是完全失败的。更糟糕的是，大型软件项目不会仅仅涉及用户在单个级别上的行为，但是涉及大团体的行为-通常是整个组织的行为。

总而言之，设计软件本身通常是工作中最容易的部分。困难的部分是重新设计人民的工作。首先很难做到；以一种不仅有效而且可以被接受的方式进行操作，仍然更加困难。

#26 楼

就像您提到的那样，空中客车A380并不是一个成功的项目。我碰巧在一家CAD / CAM公司工作，但我被告知它（我们也有空中客车公司）被推迟了几年，因为他们在不同公司使用了不同版本的软件。也就是说，在世界的不同部分设计了不同的部分。并且在集成时，他们知道所有设计都无法集成，因此他们必须在一个版本中重新设计。因此，我认为它并不成功。如果它出现在2-3年之前，它将成为空中客车公司的游戏规则改变者。航天飞机上有50％以上的软件正在运行，并且让我相信它们非常强大。仅仅是我们更加接近软件，并且有更多的软件程序，所以我们在其中看到了更多的错误。

访问：http://www.globalprojectstrategy.com/lessons/case。 php？id = 23
，看看空客A380取得了多大的成功。

#27 楼

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

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

在诸如建筑和大多数形式的工程学之类的事物中，否则这些事物将存在于“库”中在软件中已经充分设计。要建塔吗？只需从现有结构中复制并粘贴计划，并进行一些修改即可。

实际上，我决定不成为工程师的主要原因之一是，您花费了大部分时间来设计10对现有发明的改进，同时可以用于对可见性进行编程，例如社交网络。

工程学中的新设计并不多；一个非常熟练的工程师是可以将现有设计改造成新的东西或对其进行改进的人。但是，几乎每个程序员都应该修改设计，修改设计或创建新的东西。 PHP等。 10或20年前没有多少代码可以回收。当您可以在数十年后不断改进设计的时候，这与汽车或航空业是完全不同的。

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

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

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

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

小型项目更好。我妻子曾经要求我在一家大公司找到工作。最后，有人争论说大公司是坏公司……对她来说，大公司拥有很多资源，经验，功能项目管理和正确的程序。对我来说，大公司就是恐龙，您的大部分时间都花在了固定代码，测试代码和文档上。人。更多的人会放慢该项目的进度，并增加不必要的官僚作风。 WhatsApp是价值数十亿美元的“小型”项目的一个示例。这并不是说不可能进行大型项目，而是您根本不需要成千上万的人来生产价值数十亿美元的软件。

#28 楼

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

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

如果飞机像软件那样建造，我们将在其他模型上更换材料，使其容量增加一倍并每18个月就加快速度，用刚发明的产品替换每种新型号的发动机技术，同时增加游泳和寻找外星生命的能力。作为完全身临其境的电影院，工作场所结束后，彩弹射击竞技场和带深色房间的夜总会。同样的事情！ （该公司制造的飞机可以可靠地将您从A运送到B，在拥有电影院，彩弹射击和夜总会功能的飞机问世一年后，这家公司破产了。）

#29 楼

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

用例

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

用户

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

跨平台

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

#30 楼

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

换句话说，花旗银行中心站的每一年，都会有大约十分之一的机会崩溃。

最初的设计师没有意识到这些问题，但幸运的是，一个学生正在研究建筑物。

一切似乎都还不错，直到LeMessurier告诉他，他才打了一个电话。根据LeMessurier的说法，1978年，一名建筑学本科生与他联系，对LeMessurier的建筑物提出了大胆的主张：花旗银行中心可能会刮风。大量人员来维护设计缺陷的机密性。
针对建筑物周围的10个街区，制定了紧急疏散计划。

他们整夜焊接并在黎明时退出，
故事一直是个秘密，直到作家乔·莫根斯特恩（Joe Morgenstern）在一次聚会上听到它，并采访了LeMessurier。莫根斯特恩（Morgenstern）在1995年的《纽约客》中打破了这个故事。

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

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