软件开发社区始终对新想法持开放态度，以改善我们开发软件的方式，在我看来，我们的创新能力超过其他工程学科或者专业。

但是，如果我们这个相对年轻的行业未能向成熟的专业学习，这似乎是不幸的。在软件开发之外的人们一定发现了一些很棒的想法，我们可以从中受益。

我们能否描述成功(或者不成功)应用于软件开发的其他专业使用的任何想法，技术或者过程？

解决方案

Eliyahu Goldratt有一本书叫做" The Goal"，这是一本有关优化工厂的新颖商业书籍。关于如何确定现实(或者至少质疑我们自己的现实概念)，它有很多很好的讨论，还有关于瓶颈的内容，这在整体可扩展性问题时非常有用。

心理学就是其中之一。这不仅可以激励我们自己和团队成员，还可以使用技术来了解客户的实际需求，而不是客户的需求。可用性是其他面向人的因素，对软件开发很重要。

软件可能是一个技术专业，但是开发应用程序却是人类的专业。

我对大型建筑(桥梁和建筑物)总是感到惊讶，而不是对出色的软件感到惊讶。因为我们总是有更多的机会进行软件测试(单位，压力，用户接受度以及非常多的质量检查)，但请想象一下，对于一个好的结构，我们可以做些什么
拥有良好的物理和数学背景一定会提高编程技能

精益开发是一个显而易见的选择，它取自丰田汽车的制造原则，以应对强大的美国工业的规模经济。它非常适合敏捷软件工程框架

这可能有些费力，但是在打乒乓球时，我了解到，掌握了一些基本技能后，大多数错误都来自于尝试打出比实际更高的水平，而我们实际上并没有能力制造大满贯。玩保守的游戏并让其他玩家夸大自己是比较安全的。

在编码时，我尽量不要比我聪明。 (人们运行架构设计可以帮助实现这一点)。实施复杂的数据结构来管理脏读和缓存过期很快被拒绝了，因为该功能仅适用于部分用户，因此不值得使用内存或者开发人员资源。

我相信弗雷德·布鲁克斯(Fred Brooks)将其称为第二系统综合症。

我个人发现，在进行故障排除和调试时，数学和科学方面的背景非常有用。使用科学的方法，对自己施加严格的知识，保持健康的怀疑态度，并总是退回到"这个理论是否真的能最好地解释观察到的证据？"这一问题上。有助于根本原因的追踪，而不会被错误的线索所跟踪。

从某种意义上说，建筑学教会了我去思考效率。当我们在工作场所打包工作袋，拖拉木材，将电源线拖过杂乱，未完成的房间和走廊并通常摔断后背时，将一大堆木材和胶合板变成一所房子，我们很快就会学到每一个举动make必须做一些有用的事情。当我们身后有一个小企业主老板，每次我们从a点走到b点而没有带东西的时候大喊他是怎么亏钱的，这尤其如此。

在编程中，通常可以相同。但是，我们没有节省时间，而是在设法节省时间。这采取易于维护和可重复使用的代码的形式。每次我们创建一个新函数来完成与另一个函数相似的痛苦时，或者我们创建一个可以很容易地从更通用的类继承而来的新类时，却几乎是相同的，我们就在浪费时间和金钱，就像在花很多时间一样仿佛成帧者来回走了6趟来做他或者(很少有)她本可以在一趟中完成的事情。在这两种情况下，回报都是更少的时间去做大的愚蠢的工作，而更快乐的是有钱的老板。

我花了14年的时间进行工业工程类型效率研究。那教会了我如何采访人们以获取信息，尤其是当他们不合作时，以及如何从除采访之外的其他来源获取信息(在收集需求时非常有用)，以及如何进行分析思考，尤其是如何真正了解两家公司的数据角度和用户角度。这在设计数据库时特别有用。当我们不得不从分析之初就必须从许多设计欠佳的数据库中提取数据时，我们会了解哪些有效，哪些无效。与普通程序员不同，我实际上使用了来自数千个不同数据库的数据。

设计模式最初是由架构师(即设计实际建筑物的人而非软件架构师)使用的。

古老的木工说"两次测量，一次切割"一直适用于我从事的开发项目。它为第一时间努力使事情变得正确而付出红利。

有太多要数的东西，而且它们以各种方式联系在一起，使问题有点夸张，因为编程本质上是逻辑和数学的结合，旨在与任何其他领域进行交互以提供解决方案/自动执行现实情况。但是要提供此功能，我们必须实现该域逻辑的很大一部分，以使某些功能有用。

因此，软件开发不是目的，可能是解决方案，或者对每个问题的解决都暗示了领域本身的观念。

我不知道我的答案是否涵盖了这个问题，因为我认为它有点笼统。

我差点结束了在中学教授ICT的工作。我学到了很多：

• 甚至老师仍然是学生-一直在学习。
• 最好的老师也是最好的学习者
• 无论他们的技能水平如何，我们都可以从周围的人那里学到很多东西
• 准备通常是成功的关键
• 假设是所有家庭的母亲
• 技术变化太快，无法跟上所有最新发展-承认我们并不了解一切。

作为顾问，我学会了微笑并向用户提供他们所需要的一切...

我不能在一个好的公司中提到我为这种行为建模的职业。

就像我在机械工程学中所做的那样，KISS(保持简单，愚蠢)原理在这里适用。就编码而言，最有可能的是，开发人员和其他人将花费更多的时间来阅读代码，而不是编写代码。因此，对于给定的问题，尽可能地简化设计会很有帮助。在这个领域的过度工程设计甚至会使最初的开发人员在未来的六个月内挠头，说："为什么我要这么做呢？"

只是我的$ 0.02.

清单！它们不仅仅适合飞行员：

清单的力量

戴尔制造工厂的视频启发了基于队列的分布式内容聚合系统的体系结构。队列上的一条消息代表工作项，工作表，任务，零件等在工作站之间传递。

每个站点代表特定的工作定型，每个站点在将消息转发回路由以进行继续分派之前都更新了工作表。

在第一个版本处理大约每小时30K作业后，系统仍在生产7年。

第一次看到该系统"呼吸"是一个激动人心的时刻。

好奇心和韧性。

虽然不是专业，但我认为我们还需要借鉴创意类型。例如，对于作家来说，将自己锁定一段时间是很常见的，这样他们就可以不受干扰地进行写作。保罗·格雷厄姆(Paul Graham)在黑客和画家之间建立了很强的相似之处