Take the 2-minute tour ×

I've been in the embedded space for a while now, and it seems that most programmers I talk to seem to be doing things pretty much the same way it was done 15 years or more ago: Waterfall(ish) Development, command line tools and a small group uses lint.

Contrast this with the server/desktop environment, where there seems to be lots of activity related to all sorts of facets of programming:

  • XP, Scrum, Iterative, Lean/Agile
  • Continuous Integration
  • Automated Builds
  • Automated Unit Testing Frameworks
  • Refactoring tool support

Is it just that the embedded environment makes it more difficult to implement new practices or tools?
Is it that the mindset of embedded programmers steers them away from new tools/concepts?
Is it that management in the typical embedded industry behind the curve compared to IT focused fields?

I do realize that this is a generalization, and some embedded projects do use Scrum, Agile, CI, Automated Builds (in fact I worked at a company that had that in place since the 80s). But my impression is that it is a very small percentage.

share|improve this question
This question appears to be off-topic because it is a question about software management and methodology; try programmers.stackexchange.com –  amalloy Oct 16 at 0:01

10 Answers 10

up vote 13 down vote accepted

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.

share|improve this answer

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.

share|improve this answer

These some reasons I can think of:

  • 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.
share|improve this answer
I was all set to give a +1 until you had to mention they do not have time to adopt modern software methodologies. Also, the code base is definately not smaller. I've been on 60 software developer teams through one developer teams. –  Dunk Feb 12 '09 at 20:43
Compare teams of 60 developers with teams of thousands for desktop-web applications. In the average, embedded software teams are smaller. Also, I didn't meant that is not of any merit to adopt modern software methologies, but that sometimes it is too much to ask that from them. –  kgiannakakis Feb 13 '09 at 7:38
Only some of the software needs to be tested with hardware. If the HAL is thin, including abstraction for any embedded OS, the abstracted parts can be stubbed or mocked, the code can be built with a host compiler and logic tested automatically. Timing triggers can be simulated easily to test logic, but real timing tests do require the hardware. IME embedded developers tend to think that's a fatal flaw, but those who've actually experienced automated logic testing won't go back. It can be hard to grok the possibilities without seeing them firsthand. –  jasper77 Feb 2 '11 at 19:38

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.

share|improve this answer
+1: I just took a job writing firmware for a company that only had straight EE types. Yikes! I just finished a complete re-write. ;) –  Judge Maygarden Feb 12 '09 at 20:06
Your experience that most embedded programmers are electrical engineers is different from mine. Yes there are some, but I have mostly been involved with Computer Engineers and occasionally Computer Science grads. Maybe DoD contracts require a bit more Software discipline than the commercial world. –  Dunk Feb 12 '09 at 20:38
+1: I got my bachelors in EE last May but got really interested in SW, and embedded systems was a good place for me. The IDE's of the 90's comment made me laugh. If I could use VS for embedded work that would be great. I'll try to watch out for your list! –  Sean Feb 19 '09 at 18:03
Sean, if your on stackoverflow that means you're probably not one of the EE's I talked about! –  Justin Tanner Feb 19 '09 at 20:43


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.


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...


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.

share|improve this answer

I would also add a couple of points here:

  • 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
share|improve this answer
"This decreases the need for very elaborated software processes" I've found the opposite to be true. Mistakes on software only projects are far less costly to fix than having to redesign and remanufacture hardware. Embedded systems require much more rigor. –  Dunk Feb 16 '09 at 15:22
"Requirements for embedded project are often precise and better defined". In the beginning they are no better defined than a software only project. Because hardware needs to be built that can do the job, more analysis is done up front to get these right. –  Dunk Feb 16 '09 at 15:23
"embedded developpers invest less time in software processes" IME, there are hardware developers and software developers. Why would the software developers invest less time in the software process? –  Dunk Feb 16 '09 at 15:24

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.

share|improve this answer

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!")

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Your Answer


