Embedded systems are typically more resource constrained in memory, processor and IO.  Combine this with realtime responsiveness and you have a need for a discipline that has been largely lost in software development for general purpose computing.  Agile, with eXtreme Programming, supports some of those lost disciplines and necessary attention to performance. 

Embedded software may include a human-computer interface (HCI), AKA, User Interface (UI), or it may just have interfaces to other system components.  Embedded software for handheld devices, avionics, automobiles, games and even home appliances have to support an effective UI.  So the UI design issues apply to this embedded category too, but often in a very focused context.  For example, just compare the UI on a website vs. your cell phone. 

Object-oriented discipline brings a clean distinction between the interface and implementation for each component and sub-component.  In the embedded context, this makes it easy to create and exchange simulations and actual hardware components as they are developed in parallel.  And this supports continuous integration and testing from the start. 

Software engineering best practices requires building unit tests for each component.  In the Agile/eXtreme Programming (XP) discipline, the tests are written first and represent the contract for each component and for many levels of integration as executable requirements, i.e. Test-Driven Design (TDD).  This is a high standard of discipline that is even more important in the embedded context because the hardware is typically not available in early stages of the software development. 

The biggest challenge for hyper-productivity and quality is building an automated system for continuous integration and testing of components as they are developed.  It can take a year or two for typical organizations to get it right unless one commits to this goal from the start.  Kent Beck in his XP writing talks about the powerful idea of a 'safety net'.  That is a suite of tests which can take the burden of manual testing off the programmer and free them for developing new features.  If the fundamental value of computers is freeing the human mind from repetitive thinking and allowing a focus on new thinking, what is a more onerous example of repetitive thinking than typical manual testing? 

When we talk about 'legacy code' we typically mean code where the author is no longer available, can no longer remember the details, or worst case, where the source code is lost!  What a difference this safety net makes with a complete suite of automated tests for each interface for each component.  This applies as much to the embedded context as to others.  My earliest computer industry experience was with telephone switching systems for the Bell System, which were built with a 40 year expected life.  Now that's embedded and max-quality on a grand scale! 

Here's a worst case scenario.  A few years ago I was working with a team helping the The US Air Force with a long-standing, unsolvable problem - the Joint Synthetic Battlespace (JSB) project at Hanscom AFB.   Its mission was to leverage a very large collection of old and new simulation software assets for different elements that need to be coordinated and interoperate in modern warfare.  That includes: soldiers, commanders, communication technologies, tanks, fighter jets, reconnaissance airplanes and satellites, UAVs for reconnisance and attack, and much much more.  The simulations were written on different hardware and software platforms and in different, and sometimes, custom languages and tools over many decades.  The cost to rewrite these thousands of simulations was prohibitive.  So the task was to build integration software environment.  Imagine if everyone had an executable specification of the contract for each interfaces.  Well, they didn't.  If you are curious, I can tell you about our grand approach to address this challenge with a new meta-language and multiple levels of models and meta-models.