我在嵌入式领域已经有一段时间了，似乎与我交谈过的大多数程序员的工作方式似乎与 15 年或更长时间前所做的几乎相同：瀑布（ish）开发，命令行工具一小群人使用皮棉。
将此与服务器/桌面环境进行对比，那里似乎有很多与编程的各个方面相关的活动：
仅仅是嵌入式环境使实施新实践或工具变得更加困难吗？
是嵌入式程序员的心态使他们远离新工具/概念吗？
与以 IT 为重点的领域相比，典型嵌入式行业的管理层是否落后于曲线？
我确实意识到这是一种概括，一些嵌入式项目确实使用了 Scrum、敏捷、CI、自动构建（事实上，我曾在一家自 80 年代以来就已经存在的公司工作）。但我的印象是，这是一个非常小的百分比。
我们都习惯了我们的台式电脑偶尔会崩溃的事实（或者至少桌面上的一个应用程序突然消失了）。这没什么大不了的。下一个补丁会修复它。
在嵌入式空间中，您正在构建无法修补的东西。生命可能取决于您的设备（在汽车、电梯或医疗系统中）。大多数设备都已安装，然后必须在无人看管的情况下运行多年。所以嵌入的人往往非常保守。TCP/IP 通常“过于现代”。他们坚持使用具有大约 50 行汇编代码的通信“堆栈”的可信赖串行总线。
更糟糕的是，您根本没有设备上的充足空间，这意味着您无法使用使 TDD 和自动化构建成为幸福的最新编程语言之一。
其次，很多嵌入式开发环境都是专有的。如果您的供应商不支持它，您将无法获得它。Linux 在过去几年开始削弱这一点，但很多设备还不足以运行 Linux。即使是这样，CPU 的能力也将用于其他用途，而不是运行带有源代码的精美操作系统。
所以是的，有强大的力量在后台工作，以保持嵌入式空间在原处。
嵌入式开发人员是否比他们的桌面兄弟更保守？
是的，因为他们更关心犯错的后果。修补嵌入式设备是一件大事。对于桌面应用程序来说不是那么多。
在嵌入式世界中，瀑布式开发是必要的，因为您通常在构建软件的同时构建硬件。您需要尽快知道有多少内存、多少处理器速度、多大的闪存、是否需要任何特殊硬件等等……在您知道这些答案之前，硬件设计无法完成。一旦你决定了，就差不多了。重做电路板的准备时间太长了。如果你搞砸了，那么该软件将不得不解决任何缺点。通常不是理想的情况。
至于工具，这在很大程度上取决于供应商提供的内容以及开发人员的任何偏见。在一些项目中，我使用了 XP Embedded，并且得到了桌面开发人员所获得的几乎所有东西。
XP、Scrum、迭代、精益/敏捷：
由于大部分设计都是预先完成的（必要时），并且在编写代码时通常没有可用的硬件，因此快速周转过程并没有真正提供太多好处。
持续集成/自动化构建 很高兴，但不是真正必要的。什么……打开IDE并按下编译按钮大约需要15秒。
自动化单元测试
没有理由不应该这样做，但只有部分代码可以真正自动测试，因为另一部分要么依赖于硬件，要么具有其他一些依赖关系，如时序。因此，您无法真正判断代码是否可以通过自动化测试工作。
重构工具支持
嵌入式处理器产品的供应商是处理器。他们提供 IDE 支持以鼓励您购买他们的处理器。他们不可能为一个 Visual Studio 规模的开发团队支付费用，以便将所有的花里胡哨的东西添加到甚至不是他们的产品的 IDE 中。
这些我能想到的一些原因：
嵌入式程序员大多是电气工程师，而不是计算机科学家或软件工程师。
他们在自己的专业领域表现出色。与大多数计算机程序员相比，它们带来了一种更慢、更有条理的方法。在编程固件时，电气工程师知道的危险程度刚好够。
以下是我注意到电气工程师在 C 语言中所做的一些事情：
在他们的辩护中，EE 没有被训练成为计算机程序员，这不是他们的工作。我认为软件是创建嵌入式设备最难的部分。设计 PCB 和选择组件需要技巧，但与 10,000 行代码的复杂性相比，显得相形见绌。
嵌入式程序员还必须处理外观和行为类似于 90 年代 IDE 的 IDE。
这部分是规模问题。软件不是产品，产品就是产品。然而，市面上有成千上万种不同类型的微控制器和微处理器，其中最流行的几千种有 3-4 种不完全兼容的不同编译器。
所以一个给定的工具只会被几百或几千名工程师使用。
然而，在windows开发中，有数以百万计的不同层次的程序员——工具直接生产软件，也就是产品，所以它会得到更多的眼球，更多的钱。
工程师推出的每个新产品都可能有不同的处理器。
嵌入式程序员通常是软件或固件工程师，而不是程序员。工程意味着在实现之前进行一定数量的设计、设计分析和设计证明——换句话说，在编写第一行代码之前已经完成了大量工作，理想情况下，文档足够具体以至于实现只是转向将文档之类的伪代码转换为可编译代码。
设计阶段需要新的工具和概念，而不是实施阶段。带有智能感知的 IDE 可能不错，但是在编写代码时它已经变得毫无用处了——他们已经知道自己需要什么。
CAD - 计算机辅助设计 - 正在为固件工程师开发工具，这些工具在设计阶段用于开发直接转化为代码的模型和模拟。Matlab 和 simulink 就是很好的例子。设计了整个系统。
事实上，人们可能想知道为什么软件开发人员仍在编写代码，而工程师则在制作数据/程序流程图和状态机图。为什么 UML 在应用程序领域的应用如此缓慢？听起来应用程序开发人员可以使用嵌入式系统工程师常用的一些工具......
实际上，很可能是相反的。当一个项目开始时，工程师必须选择处理器。
处理器制造商在较旧的芯片上获得的资金较少，因此他们推销最新和最好的芯片，而且它们总体上比以前设计中使用的芯片便宜（通过芯片缩小、更多集成等）。
所以设计实际上是使用了最新最好的芯片。
缺点是编译器和工具通常不成熟。他们只能在旧工具上构建这么多东西，而且由于目标随着每个新处理器的变化而变化，他们不能专注于应用程序程序员可能喜欢的许多不错的功能。特别是因为其中许多功能对嵌入式工程师没有用处。
还有许多其他因素，其中一些被其他答案列举，但它确实是一个不同的领域，即使它们都涉及编程。
-亚当
我还要在这里补充几点：
我同意这里写的很多内容：
没有花里胡哨的旧工具（由于 C/C++ 的预处理器指令，可用的重构要少得多，如果有的话）（选择单元测试框架与简单地使用 JUnit 比较耗时）。
的确，瀑布感觉更有效率。如果我要打开引擎盖并进入一个难以进入的地方，我会想在那里做尽可能多的事情，而不是在完成每个任务后退出并关闭引擎盖只是为了打开再说一遍。首先创建最重要的功能允许您选择在承诺时发货而不是迟到的想法，当您认为没有什么是可选的时，也很难理解，这可能是真的。然而，当最后期限临近时，输入法总是变得不必要。
对系统的较少可见性使得重新访问现有代码以重构或更改功能的风险更大。通常存在时间问题，使用存根和模拟在主机上运行的自动化测试无法捕捉到。被这些问题困扰的人可能很难采取不同的观点。
我再补充一个；敏捷/scrum 的语言是工作站程序员的术语。对于一个懂得足够 C 语言来完成工作的嵌入式开发人员来说，什么是类、对象或方法？当“用户”通常被认为是点击和打字的物理人，并且产品没有人的用户界面时，很容易将这个想法视为不适用。这可能会随着 James Grenning 即将出版的关于C 中 TDD的书而改变。我一直在阅读测试版电子书，它非常好。
我会说它更缺乏好的工具集。当你想使用 C++ 来使用 C 中不存在的编译时特性（模板、命名空间、面向对象等）而不是它的运行时特性（异常、虚函数）时，这真的很令人沮丧——但是设备制造商和第三方只是给你一个 C 编译器，而不是 C++。这可能更多是由于市场规模（数亿台运行 Windows 的 PC，拥有数十万甚至数百万开发人员 - 与数十万 Chip X，拥有数百或数千名开发人员）而不是设备能力的结果。
编辑：w/r/t 稳健性：那里有不同的市场。汽车/电梯/航空/医疗设备市场必须严格消除漏洞。其他市场（玩具、MP3 播放器和其他消费电子产品）可能不那么严格，特别是如果可以在现场升级代码的话。（“糟糕！很抱歉我们删除了您的音乐库！我们刚刚修复了这个错误，您可以在方便时在我们的网站上获取最新版本！”）
我会说不同类型的问题环境。
瀑布方法的最大问题是需求变化。在我所经历的每一个环境中，至少存在需求变化的可能性，这意味着成功的方法是那些尽可能长时间地保持灵活性的方法。即使客户已经签署了血案，并且如果他提出更改建议，他会放弃他的左手，未来也会有更改。
在嵌入式编程中，可以预先确定需求。它们来自整个系统的行为，工程师擅长确定系统要求。没有人会在中途说用户现在希望起搏器在接受者跳舞时提供切分脉冲。
一旦需求被冻结而无法解冻，这在为人类使用而设计的软件中永远不会发生，瀑布是一种非常有效的方法。团队从明确规定的需求到整体设计，然后是详细设计，然后是编码，一直验证各个阶段是否正确完成。然后是调试代码的时候了（因为它在编写时永远不会完美），并进行最终测试以确保代码符合要求。
我还假设某些领域本质上是保守的。例如运输业，火车和飞机的寿命可能在 30 年左右。客户往往需要经过验证的真实实践，这些实践可能源自 IEEE。瀑布是客户所知道的，瀑布是客户所要求的。