We are all used to the fact that our desktop PC crashes once in a while (or at least an application on the desktop suddenly disappears). It's no big deal. The next patch will fix it.
In the embedded space, you are building something which can't be patched. Lives can depend on your device (in a car, an elevator or a medical system). Most devices are installed and then must run unattended for years. So embedded people tend to be very conservative. TCP/IP is often "too modern". They stick to their trusty serial bus with a communication "stack" that is roughly 50 lines of assembler code.
What's worse, you simply don't have the abundance of space on the device which means you can't use one of the latest programming languages which make TDD and automated builds a bliss.
Next, a lot of embedded development environments are proprietary. If your supplier doesn't support it, you won't get it. Linux has started to weaken this in the past years but a whole lot of devices are not powerful enough to run Linux, yet. And even if they were, the CPU power would be used for something else instead of running a fancy OS which comes with source.
So yes, there are powerful forces working in the background to keep the embedded space where it is.
嵌入式处理器产品的供应商就是处理器。 他们提供 IDE 支持以鼓励您购买他们的处理器。 他们不可能支付 Visual Studio 规模的开发团队的费用，以便将所有花哨的功能添加到 IDE 中，而 IDE 甚至不是他们的产品。
Are embedded developers more conservative than their desktop brethrens?
Yes, because they are more concerned with the consequences of making errors. It’s a big deal to patch an embedded device. Not so much for a desktop app.
Waterfallish development is necessary in the embedded world because you are generally building hardware at the same time as the software. You need to know as soon as possible how much memory, how much processor speed, how big a flash, what if any special hardware is necessary etc...The hardware design can’t complete until you know these answers. Once you decide, that is pretty much it. The lead time for redoing a board is far too long. If you mess up then the software is going to have to work around any short-comings. Not usually an ideal situation.
As for the tools, that is largely based on what the supplier provides and any biases of the developers. On some projects I have used XP Embedded and got pretty much everything that the desktop developer gets.
XP, Scrum, Iterative, Lean/Agile:
Since most of the design is done up front (by necessity), and you usually don’t have working hardware when it is time to code, the quick turn-around processes don’t really provide much benefit.
Continuous Integration/Automated Builds Nice to have, but not really necessary. What…it takes about 15 seconds to open the IDE and press the compile button.
Automated Unit Testing
No reason why this shouldn't be done, but only part of the code can truly be automatically tested because the other part is either hardware dependent or has some other dependencies like timing. So you can't really tell if the code is working by the automated tests.
Refactoring Tool Support
The vendors of embedded processors product is the processor. They provide the IDE support in order to encourage you to purchase their processor. They couldn't possibly afford to pay for a Visual Studio sized development team in order to add all the bells and whistles to the IDE which isn't even their product.
Embedded teams are usually smaller that desktop/Web teams. Code base is smaller.
System testing is much more important than unit testing. The software needs to be tested together with hardware. Automated testing is not possible and can only be applied to a small fraction of the code base.
Embedded engineers have a different skill set than software engineers. They interact with hardware, know how to use an oscilloscope and a logic analyzer. Usually, the difficult part of their job is to find a glitch in the hardware. They do not have the time to adopt modern software methologies.
Embedded programmers are mostly electrical engineers, not computer scientists or software engineers.
They excel in their field of expertise. They bring a slower more methodical approach than most computer programmers. When it comes to programming firmware, electrical engineers know just enough to be dangerous.
Here are some of the things I've noticed electrical engineers doing in C:
All code in ONE single file
Math like variable names: x, y, z
No or missing indentation
No stardard comment headers
No comments at all
Too many comments
In their defense EE's didn't train to be computer programmers, it's not their job. I think software is the hardest part of creating embedded devices. Designing PCBs and choosing components requires skill but pales in comparison to the complexity of 10,000 lines of code.
Embedded programmers also have to deal IDE's that look and behave like the IDE's of the 90's.
Is it just that the embedded environment makes it more difficult to implement new practices or tools?
It's partly a matter of scale. Software is NOT the product, the product is the product. however, there are thousands of different types of microcontrollers and microprocessors out there, and the most popular thousand have 3-4 different compilers that aren't completely compatible.
So a given tool is only going to be used by a few hundred or thousand engineers.
In windows development, however, there are millions of programmers of many levels - the tools produce software directly which is the product, and so it's going to get more eyeballs, and more money.
Each new product that an engineer puts out might have a different processor.
Is it that the mindset of embedded programmers steers them away from new tools/concepts?
Embedded programmers are generally software or firmware engineers, as opposed to programmers. Engineering implies a certain amount of design, design analysis, and design proof prior to implementation - in other words a ton of work is done before the first line of code is written, and the documentation, ideally, is specific enough that implementation is merely turning pseudocode like documentation into compilable code.
New tools and concepts are needed in the design phase, not the implementation phase. An IDE with intellisense may be nice, but by the time the code is being written it's useless cruft - they already know what they need.
CAD - computer aided design - tools are being developed for firmware engineers that are used in the design phase to develop models and simulations that are directly turned into code. Matlab and simulink are good examples of this. The system as a whole is designed.
In fact, one might wonder why software developers are still writing code while the engineers are making data/program flow charts and state machine diagrams. Why is UML uptake so slow in the application world? It sounds like application developers can use some of the tools in common use among embedded systems engineers...
Is it that management in the typical embedded industry behind the curve compared to IT focused fields?
Actually, it's likely the reverse. When a project starts the engineers have to pick the processor.
The processor manufacturers get less money on older chips, so they pitch the latest and greatest, and they are generally cheaper overall than the chips used in the previous design (either by die shrinks, more integration, etc).
So the design is actually using the latest and greatest chips.
The downside is that the compiler and tools are often immature. They can only build so much on the older tools, and since the target moves with each new processor, they can't focus on a lot of the nice features application programmers might like. Especially since many of those features won't be useful to an embedded engineer.
There are many other factors, some of which are enumerated by other answers, but it's really a different field even though they both involve programming.
In general embedded projects tend to be smaller than desktop projects. This decreases the need for very elaborated software processes.
Requirements for embedded project are often precise and better defined. Therefore SCRUM and agile are not so crucial
Finally embedded projects are generally a mix of software and hardware. The software being only a part of the project embedded developpers invest less time in software processes
我再添加一个； 敏捷/Scrum 语言是工作站程序员的术语。 对于了解足够 C 语言来完成工作的嵌入式开发人员来说，什么是类、对象或方法？ 当“用户”通常被视为点击和打字的实体人，并且产品没有人性用户界面时，很容易认为这个想法不适用。 随着 James Grenning 即将出版的关于 TDD in C< 的书，这种情况可能会改变/a>. 我一直在阅读测试版电子书，它相当不错。
I agree with much that's been written here:
Old tools without the bells and whistles (far fewer refactorings available due to C/C++'s preprocessor directives, if any at all) (time consuming to choose a unit test framework vs simply using JUnit).
It's true that waterfall feels more efficient. If I'm going to open the hood and get into a hard-to-access place, I'll want to do as much as I can while I'm there, rather than exiting and closing the hood after each task just to open it again. The idea that creating the most important features first allows you the option of shipping when promised instead of going late can also be hard to grasp when you believe nothing is optional, which might be true. IME, though, when the deadline looms something always becomes unnecessary.
Less visibility into the system makes it riskier to revisit existing code to refactor or change functionality. There are often timing issues, which automated tests running on the host using stubs and mocks won't catch. It can be hard for someone who's been bitten by these issues to take a different perspective.
I'll add one more; the language of agile/scrum is in workstation programmer's terms. To an embedded developer who knows just enough C to get the job done, what is a class, object, or method? When the "user" is typically regarded as a physical person clicking and typing, and the product has no person user interface, it's easy to dismiss the idea as Not Applicable. This may change with James Grenning's forthcoming book about TDD in C. I've been reading the beta ebook and it's quite good.
我想说更多的是缺乏好的工具集。 当您想要使用 C++ 来使用 C 中不存在的编译时功能（模板、命名空间、面向对象等）而不是其运行时功能（异常、虚拟函数）时，这真的很令人沮丧 - 但是设备制造商和设备制造商; 第 3 方只给你一个 C 编译器，而不是 C++。 这可能更多地取决于市场规模（数亿台运行 Windows 的 PC，拥有数十万甚至数百万的开发人员，而数十万的 Chip X，拥有数百或数千名开发人员），而不是设备功能。
I would say it's more lack of good toolsets. It's really frustrating when you want to use C++ for its compile-time features not present in C (templates, namespaces, object-orientedness, etc) rather than its run-time features (exceptions, virtual functions) -- but the device manufacturers & 3rd parties just give you a C compiler, not C++. This probably results more from market size (hundreds of millions of PCs running Windows, with hundreds of thousands or even millions of developers -- vs. hundreds of thousands of Chip X, with hundreds or low thousands of developers) than from device capability.
edit: w/r/t robustness: there are different markets out there. The car/elevator/aeronautics/medical device market is going to have to be rigorous about getting rid of bugs. Other markets (toys, MP3 players, & other consumer electronics) can be less rigorous, especially if it's possible to upgrade code in the field. ("Oops! We're sorry we deleted your music library! We just fixed that bug, you can grab the latest release at our website at your convenience!")
The biggest problem with the waterfall methodology is that requirements change. In every environment I've been in, there has been at least the likelihood of a requirements change, which means that the successful methodologies are those that keep flexibility as long as possible. Even if the customer has signed off in blood, and stands to forfeit his left hand if he suggests a change, there are changes coming in the future.
In embedded programming, it is possible to nail the requirements down up front. They come from the behavior of the system as a whole, and engineers are good at nailing down system requirements. Nobody's going to come in halfway through and say that the user now wants the pacemaker to deliver syncopated impulses while the recipient is dancing.
Once the requirements are frozen beyond thawing, which never happens in software designed for human use, waterfall is a very efficient methodology. The team proceeds from well-specified requirements to overall design, then detailed design, then coding, verifying all the way that the stages are done correctly. Then it's time to debug the code (since it's never perfect when written), and final tests to make sure the code meets the requirements.
I would also posit that some fields are inherently conservative. The transportation industry for example, where trains and planes may have life spans of 30 years or so. Customers tend to require tried and true practices, probably derived from IEEE. Waterfall is what customers know, waterfall is what customers demand.
发布评论
评论（10）
我们都习惯了这样的事实：我们的台式电脑偶尔会崩溃（或者至少桌面上的应用程序突然消失）。 没什么大不了的。 下一个补丁将修复它。
在嵌入式空间中，您正在构建一些无法修补的东西。 生命可能取决于您的设备（汽车、电梯或医疗系统中）。 大多数设备安装完毕后必须在无人值守的情况下运行数年。 所以嵌入的人往往非常保守。 TCP/IP 通常“太现代”。 他们坚持使用可靠的串行总线，并使用大约 50 行汇编代码的通信“堆栈”。
更糟糕的是，您的设备上根本没有足够的空间，这意味着您无法使用最新的编程语言之一，而这使得 TDD 和自动化构建成为一种幸福。
其次，许多嵌入式开发环境都是专有的。 如果您的供应商不支持，您将无法获得。 在过去的几年里，Linux 已经开始削弱这一点，但目前很多设备的功能还不足以运行 Linux。 即使是这样，CPU 的能力也会被用于其他用途，而不是运行带有源代码的精美操作系统。
所以，是的，有强大的力量在后台工作，以保持嵌入式空间的原样。
We are all used to the fact that our desktop PC crashes once in a while (or at least an application on the desktop suddenly disappears). It's no big deal. The next patch will fix it.
In the embedded space, you are building something which can't be patched. Lives can depend on your device (in a car, an elevator or a medical system). Most devices are installed and then must run unattended for years. So embedded people tend to be very conservative. TCP/IP is often "too modern". They stick to their trusty serial bus with a communication "stack" that is roughly 50 lines of assembler code.
What's worse, you simply don't have the abundance of space on the device which means you can't use one of the latest programming languages which make TDD and automated builds a bliss.
Next, a lot of embedded development environments are proprietary. If your supplier doesn't support it, you won't get it. Linux has started to weaken this in the past years but a whole lot of devices are not powerful enough to run Linux, yet. And even if they were, the CPU power would be used for something else instead of running a fancy OS which comes with source.
So yes, there are powerful forces working in the background to keep the embedded space where it is.
嵌入式开发人员比桌面开发人员更保守吗？
是的，因为他们更关心犯错误的后果。 给嵌入式设备打补丁是一件大事。 对于桌面应用程序来说就不那么重要了。
瀑布式开发在嵌入式世界中是必要的，因为您通常在构建软件的同时构建硬件。 你需要尽快知道有多少内存、多少处理器速度、多大的闪存、是否需要任何特殊硬件等等……只有知道这些答案，硬件设计才能完成。 一旦你决定了，那就差不多了。 重做电路板的准备时间太长了。 如果你搞砸了，那么该软件将不得不解决任何缺陷。 通常不是理想的情况。
至于工具，这很大程度上取决于供应商提供的内容以及开发人员的偏见。 在一些项目中，我使用了 XP Embedded，并获得了桌面开发人员所能获得的几乎所有内容。
XP、Scrum、迭代、精益/敏捷：
由于大部分设计都是预先完成的（必然），并且在编码时通常没有可用的硬件，因此快速转向-around 流程并没有真正提供太多好处。
持续集成/自动构建
很高兴拥有，但并不是真正必要。 什么……打开IDE并按下编译按钮大约需要15秒。
自动化单元测试
没有理由不这样做，但只有部分代码可以真正进行自动测试，因为另一部分要么依赖于硬件，要么具有一些其他依赖项（例如计时）。 因此，您无法通过自动化测试真正判断代码是否有效。
重构工具支持
嵌入式处理器产品的供应商就是处理器。 他们提供 IDE 支持以鼓励您购买他们的处理器。 他们不可能支付 Visual Studio 规模的开发团队的费用，以便将所有花哨的功能添加到 IDE 中，而 IDE 甚至不是他们的产品。
Are embedded developers more conservative than their desktop brethrens?
Yes, because they are more concerned with the consequences of making errors. It’s a big deal to patch an embedded device. Not so much for a desktop app.
Waterfallish development is necessary in the embedded world because you are generally building hardware at the same time as the software. You need to know as soon as possible how much memory, how much processor speed, how big a flash, what if any special hardware is necessary etc...The hardware design can’t complete until you know these answers. Once you decide, that is pretty much it. The lead time for redoing a board is far too long. If you mess up then the software is going to have to work around any short-comings. Not usually an ideal situation.
As for the tools, that is largely based on what the supplier provides and any biases of the developers. On some projects I have used XP Embedded and got pretty much everything that the desktop developer gets.
XP, Scrum, Iterative, Lean/Agile:
Since most of the design is done up front (by necessity), and you usually don’t have working hardware when it is time to code, the quick turn-around processes don’t really provide much benefit.
Continuous Integration/Automated Builds
Nice to have, but not really necessary. What…it takes about 15 seconds to open the IDE and press the compile button.
Automated Unit Testing
No reason why this shouldn't be done, but only part of the code can truly be automatically tested because the other part is either hardware dependent or has some other dependencies like timing. So you can't really tell if the code is working by the automated tests.
Refactoring Tool Support
The vendors of embedded processors product is the processor. They provide the IDE support in order to encourage you to purchase their processor. They couldn't possibly afford to pay for a Visual Studio sized development team in order to add all the bells and whistles to the IDE which isn't even their product.
我能想到的一些原因：
These some reasons I can think of:
嵌入式程序员大多是电气工程师，而不是计算机科学家或软件工程师。
他们在自己的专业领域表现出色。 他们带来了比大多数计算机程序员更慢、更有条理的方法。 当谈到固件编程时，电气工程师所知道的知识足以带来危险。
以下是我注意到电气工程师在 C 语言中所做的一些事情：
在他们的辩护中EE 没有接受过计算机程序员培训，这不是他们的工作。 我认为软件是创建嵌入式设备最难的部分。 设计 PCB 和选择元件需要一定的技巧，但与 10,000 行代码的复杂性相比就显得苍白无力了。
嵌入式程序员还必须处理外观和行为类似于 90 年代 IDE 的 IDE。
Embedded programmers are mostly electrical engineers, not computer scientists or software engineers.
They excel in their field of expertise. They bring a slower more methodical approach than most computer programmers. When it comes to programming firmware, electrical engineers know just enough to be dangerous.
Here are some of the things I've noticed electrical engineers doing in C:
In their defense EE's didn't train to be computer programmers, it's not their job. I think software is the hardest part of creating embedded devices. Designing PCBs and choosing components requires skill but pales in comparison to the complexity of 10,000 lines of code.
Embedded programmers also have to deal IDE's that look and behave like the IDE's of the 90's.
难道只是嵌入式环境使新实践或工具的实施变得更加困难？
这在一定程度上是规模问题。 软件不是产品，产品才是产品。 然而，市面上有数千种不同类型的微控制器和微处理器，其中最流行的数千种具有 3-4 个不完全兼容的不同编译器。
因此，一个给定的工具只会被几百或几千个工程师使用。
然而，在 Windows 开发中，有数以百万计的不同级别的程序员 - 工具直接生成软件，即产品，因此它将获得更多的眼球和更多的钱。
工程师推出的每个新产品可能都有不同的处理器。
嵌入式程序员的心态是否让他们远离新工具/概念？
嵌入式程序员通常是软件或固件工程师，而不是程序员。 工程意味着在实现之前进行一定量的设计、设计分析和设计验证——换句话说，在编写第一行代码之前已经完成了大量工作，并且文档在理想情况下足够具体，以至于实现只是转向伪代码就像将文档转换为可编译代码。
设计阶段需要新的工具和概念，而不是实施阶段。 具有智能感知功能的 IDE 可能很好，但在编写代码时，它已经毫无用处——他们已经知道自己需要什么。
CAD（计算机辅助设计）工具正在为固件工程师开发，用于在设计阶段开发直接转化为代码的模型和模拟。 Matlab 和 simulink 就是很好的例子。 系统是整体设计的。
事实上，人们可能想知道为什么软件开发人员仍在编写代码，而工程师却在制作数据/程序流程图和状态机图。 为什么 UML 在应用程序领域的采用如此缓慢？ 听起来应用程序开发人员可以使用嵌入式系统工程师常用的一些工具……
与以 IT 为重点的领域相比，典型嵌入式行业的管理是否落后？
事实上，情况很可能恰恰相反。 当项目开始时，工程师必须选择处理器。
处理器制造商在旧芯片上获得的资金较少，因此他们推出最新和最好的芯片，而且它们总体上通常比以前设计中使用的芯片更便宜（通过芯片缩小、更高的集成度等）。
所以设计实际上是使用了最新、最好的芯片。
缺点是编译器和工具往往不成熟。 他们只能在旧工具上构建这么多，并且由于目标随着每个新处理器的变化而变化，因此他们无法专注于应用程序程序员可能喜欢的许多出色功能。 特别是因为其中许多功能对于嵌入式工程师来说没有用处。
还有许多其他因素，其中一些已被其他答案列举，但这确实是一个不同的领域，即使它们都涉及编程。
-亚当
Is it just that the embedded environment makes it more difficult to implement new practices or tools?
It's partly a matter of scale. Software is NOT the product, the product is the product. however, there are thousands of different types of microcontrollers and microprocessors out there, and the most popular thousand have 3-4 different compilers that aren't completely compatible.
So a given tool is only going to be used by a few hundred or thousand engineers.
In windows development, however, there are millions of programmers of many levels - the tools produce software directly which is the product, and so it's going to get more eyeballs, and more money.
Each new product that an engineer puts out might have a different processor.
Is it that the mindset of embedded programmers steers them away from new tools/concepts?
Embedded programmers are generally software or firmware engineers, as opposed to programmers. Engineering implies a certain amount of design, design analysis, and design proof prior to implementation - in other words a ton of work is done before the first line of code is written, and the documentation, ideally, is specific enough that implementation is merely turning pseudocode like documentation into compilable code.
New tools and concepts are needed in the design phase, not the implementation phase. An IDE with intellisense may be nice, but by the time the code is being written it's useless cruft - they already know what they need.
CAD - computer aided design - tools are being developed for firmware engineers that are used in the design phase to develop models and simulations that are directly turned into code. Matlab and simulink are good examples of this. The system as a whole is designed.
In fact, one might wonder why software developers are still writing code while the engineers are making data/program flow charts and state machine diagrams. Why is UML uptake so slow in the application world? It sounds like application developers can use some of the tools in common use among embedded systems engineers...
Is it that management in the typical embedded industry behind the curve compared to IT focused fields?
Actually, it's likely the reverse. When a project starts the engineers have to pick the processor.
The processor manufacturers get less money on older chips, so they pitch the latest and greatest, and they are generally cheaper overall than the chips used in the previous design (either by die shrinks, more integration, etc).
So the design is actually using the latest and greatest chips.
The downside is that the compiler and tools are often immature. They can only build so much on the older tools, and since the target moves with each new processor, they can't focus on a lot of the nice features application programmers might like. Especially since many of those features won't be useful to an embedded engineer.
There are many other factors, some of which are enumerated by other answers, but it's really a different field even though they both involve programming.
-Adam
我还要在这里补充几点：
I would also add a couple of points here:
我同意这里写的很多内容：
没有花哨功能的旧工具（由于 C/C++ 的预处理器指令，可用的重构要少得多，如果有的话）（选择单元测试框架与简单地使用 JUnit 相比，耗时）。
确实，瀑布感觉更高效。 如果我要打开引擎盖并进入一个难以进入的地方，我会想在那里做尽可能多的事情，而不是在每次任务完成后退出并关闭引擎盖只是为了打开再来一次。 首先创建最重要的功能可以让您选择在承诺时发货而不是延迟发货，当您认为没有什么是可选的时，这种想法也很难理解，这可能是真的。 然而，当截止日期临近时，IME 总是变得不必要。
系统可见性较低，重新访问现有代码以重构或更改功能的风险更大。 通常存在计时问题，使用存根和模拟在主机上运行的自动化测试无法捕获这些问题。 对于遇到这些问题的人来说，很难采取不同的观点。
我再添加一个； 敏捷/Scrum 语言是工作站程序员的术语。 对于了解足够 C 语言来完成工作的嵌入式开发人员来说，什么是类、对象或方法？ 当“用户”通常被视为点击和打字的实体人，并且产品没有人性用户界面时，很容易认为这个想法不适用。 随着 James Grenning 即将出版的关于 TDD in C< 的书，这种情况可能会改变/a>. 我一直在阅读测试版电子书，它相当不错。
I agree with much that's been written here:
Old tools without the bells and whistles (far fewer refactorings available due to C/C++'s preprocessor directives, if any at all) (time consuming to choose a unit test framework vs simply using JUnit).
It's true that waterfall feels more efficient. If I'm going to open the hood and get into a hard-to-access place, I'll want to do as much as I can while I'm there, rather than exiting and closing the hood after each task just to open it again. The idea that creating the most important features first allows you the option of shipping when promised instead of going late can also be hard to grasp when you believe nothing is optional, which might be true. IME, though, when the deadline looms something always becomes unnecessary.
Less visibility into the system makes it riskier to revisit existing code to refactor or change functionality. There are often timing issues, which automated tests running on the host using stubs and mocks won't catch. It can be hard for someone who's been bitten by these issues to take a different perspective.
I'll add one more; the language of agile/scrum is in workstation programmer's terms. To an embedded developer who knows just enough C to get the job done, what is a class, object, or method? When the "user" is typically regarded as a physical person clicking and typing, and the product has no person user interface, it's easy to dismiss the idea as Not Applicable. This may change with James Grenning's forthcoming book about TDD in C. I've been reading the beta ebook and it's quite good.
我想说更多的是缺乏好的工具集。 当您想要使用 C++ 来使用 C 中不存在的编译时功能（模板、命名空间、面向对象等）而不是其运行时功能（异常、虚拟函数）时，这真的很令人沮丧 - 但是设备制造商和设备制造商; 第 3 方只给你一个 C 编译器，而不是 C++。 这可能更多地取决于市场规模（数亿台运行 Windows 的 PC，拥有数十万甚至数百万的开发人员，而数十万的 Chip X，拥有数百或数千名开发人员），而不是设备功能。
编辑：w/r/t稳健性：那里有不同的市场。 汽车/电梯/航空/医疗设备市场必须严格消除错误。 其他市场（玩具、MP3 播放器和其他消费电子产品）可能不太严格，特别是如果可以在现场升级代码的话。 （“哎呀！我们很抱歉我们删除了您的音乐库！我们刚刚修复了该错误，您可以在方便时在我们的网站上获取最新版本！”）
I would say it's more lack of good toolsets. It's really frustrating when you want to use C++ for its compile-time features not present in C (templates, namespaces, object-orientedness, etc) rather than its run-time features (exceptions, virtual functions) -- but the device manufacturers & 3rd parties just give you a C compiler, not C++. This probably results more from market size (hundreds of millions of PCs running Windows, with hundreds of thousands or even millions of developers -- vs. hundreds of thousands of Chip X, with hundreds or low thousands of developers) than from device capability.
edit: w/r/t robustness: there are different markets out there. The car/elevator/aeronautics/medical device market is going to have to be rigorous about getting rid of bugs. Other markets (toys, MP3 players, & other consumer electronics) can be less rigorous, especially if it's possible to upgrade code in the field. ("Oops! We're sorry we deleted your music library! We just fixed that bug, you can grab the latest release at our website at your convenience!")
我想说的是不同类型的问题环境。
瀑布方法的最大问题是需求的变化。 在我经历过的每个环境中，至少存在需求变更的可能性，这意味着成功的方法是那些尽可能长时间保持灵活性的方法。 即使顾客已经血淋淋地签字同意，如果他建议改变，他就会失去左手，但未来也会有改变。
在嵌入式编程中，可以预先确定需求。 它们来自整个系统的行为，工程师擅长确定系统需求。 没有人会中途介入并说用户现在希望起搏器在接收者跳舞时传递切分音脉冲。
一旦需求被冻结而无法解冻（这种情况在为人类使用而设计的软件中从未发生过），瀑布就是一种非常有效的方法。 团队从明确的需求到整体设计，然后是详细设计，然后编码，验证各个阶段是否正确完成。 然后是调试代码（因为编写时永远不会完美）和最终测试以确保代码满足要求的时候了。
I'd say different sorts of problem environments.
The biggest problem with the waterfall methodology is that requirements change. In every environment I've been in, there has been at least the likelihood of a requirements change, which means that the successful methodologies are those that keep flexibility as long as possible. Even if the customer has signed off in blood, and stands to forfeit his left hand if he suggests a change, there are changes coming in the future.
In embedded programming, it is possible to nail the requirements down up front. They come from the behavior of the system as a whole, and engineers are good at nailing down system requirements. Nobody's going to come in halfway through and say that the user now wants the pacemaker to deliver syncopated impulses while the recipient is dancing.
Once the requirements are frozen beyond thawing, which never happens in software designed for human use, waterfall is a very efficient methodology. The team proceeds from well-specified requirements to overall design, then detailed design, then coding, verifying all the way that the stages are done correctly. Then it's time to debug the code (since it's never perfect when written), and final tests to make sure the code meets the requirements.
我还认为某些领域本质上是保守的。 以交通运输业为例，火车和飞机的使用寿命可能有30年左右。 客户往往需要经过验证的、真实的实践，这些实践可能源自 IEEE。 瀑布是客户知道的，瀑布是客户需求的。
I would also posit that some fields are inherently conservative. The transportation industry for example, where trains and planes may have life spans of 30 years or so. Customers tend to require tried and true practices, probably derived from IEEE. Waterfall is what customers know, waterfall is what customers demand.