2. Tell me more about techniques for dual targeting my code (for test purposes) to both a PC and the embedded system.

3. Practical suggestions for continuous integration, including automatic testing on the embedded target.

4. Examples of defining test scripts that are comprehendable (easily readable) by the rest of the disciplines in the engineering department. Ideally, perhaps persons other than software engineers could be writing these test scripts.

5. Discussion about test frameworks that has absolute minimum impact on the embedded target’s resources (ie, memory, etc). Eg, shifting some of the framework from the target onto a host with more resources.

6. Testing an embedded system where the target is one node of a larger embedded network.

7. Suggestions for increasing the visibility into the target, particularly regarding time.

8. Tips for applying TDD and Agile to embedded development, particularly in a community that is not convinced of the benefits or willing to invest the effort required. How can an agile engineer work within a non-agile team?

- What is the best way to increase meeting attendance?
– If engineers have “nothing to say everyday” what value is their attendance?
– If managers have no problem regularly excusing specific engineers from team meetings how is this overcome?

- Does an agile embedded team ideally have a lab in their team room?

- An engineer states “I already know how to do my job. I don’t need training.” How can this attitude be overcome?

- It’s harder to change people behavior than to implement a technical solution that won’t work anyway How do we help engineers and management to choose the harder path?

Maybe that’s enough from me. ;^)

I would want some “killer sentences” that say what it is and why its beneficial. A mantra if you will.

Cutting through the hype, how do I take back to the office something I can do within a short period of time, for at least some immediate results.

To counter the “my code is complicated, because it is complicated”.
Show me how to test my code. I think I know, but when you explain it, with “real world code”, with some real bug, that could have been avoided, easily with teh most simple of tests.