In reply to Alex Zhu.

The key to being agile in the embedded world is to remove the dependency on hardware from the driver. This is the true Supertanker in the ocean of code development. I've been involved with several bring-ups where a test cycle for a simple change can take 20 minutes or more to validate the change. Given the rapid nature of change during the bringup period, this can result in hours of time spent compiling/loading/testing, often on trivial errors.

Specifically with our own ASIC's, we can do a better job of combining the tasks of ASIC validation with the development of a driver which can be integrated with the intended operating systems. Use of test-driven-development (TDD) along with hardware mocks, it becomes much easier to test the behavior of driver code on a device without actually needing access to the physical device. The developer has the ability to rapidly test changes to the driver on their development system, with a feedback in an order of seconds rather than minutes.

Some points to consider when talking about Agile development:
- What is the cycle time between making a software change, and confirming existing behavior is not affected? Are there external dependencies?
- How many resources (ie switches/routers/servers) are required to validate a given feature?
- How are failure cases validated? Can this be performed without damaging a system?
- Are component drivers or critical infrastructure tightly interleaved with a particular implementation? If this module was to be ported over to another system, how much work would be involved integrating it into a new system.
- How easy is it to roll back changes in the case of failure? Are there any automation routines occurring (ie continuous integration) to ensure check-ins do not break previously passing test cases? Or is validation dependent on hands-on testing? Are hooks in place to run specific test cases before changes can be checked into the software repository?