Let’s say you were an embedded systems developer, and you were planning on attending a conference like the Deep Agile Embedded.
What questions would you hope you could get answers for at the conference?
What if you already knew it all but were sending your boss, co-worker, or CEO who needed to learn more, what would you want them to hear about?
Would you want to do some hands on Test Driven Development?
Here are some of the questions we have so far:
- In practice, how can a hardware-based system be delivered incrementally? Isn’t it more work – and more expense – to do it that way?
- With agile iterations only a few weeks long, do agile teams really expect to modify hardware that frequently?
- Extreme Programming says that you need to have an onsite customer. But so many embedded systems have thousands of customers who are not even aware of the system – e.g. if your software controls anti-lock brakes in a car, how can a car buyer be expected to interact with the team to help them design that software?
- Because hardware lead-times are long, don’t you have to design most of the system up-front? Isn’t this against what agile calls for?
- If you’re planning an iteration at a time, how can you possibly be sure of hitting a hard deadline?
- How can you do automated test on software that is driving device hardware – like motors, or sensors?
- Embedded systems and software are not delivered incrementally, doesn’t that make Agile inappropriate for most embedded development?
- In embedded systems development hardware, software and mechanics are built concurrently. That means a BDUF is needed. Comments?
- Some embedded software deliverables, take more than 2 weeks to deliver, a device driver for example, also it is not visible to the “customer”, how does agile handle that?
- Hardware is often not ready until late in the product cycle, how can testing be continuous from the beginning without hardware.
- We only get one chance to deliver, how can you say that some features will be cut.
- We had a team doing agile. To them that included not doing any documentation. We need documentation once we go into maintenance. Is doing documentation allowed in Agile?
- When the features are broken into little pieces and ordered by the customer, what if something near the end of the release causes major rework?
- I’m concerned about the lack of up-front design. What if some story causes a lot of rework to the current design?
I would want to know about tools that enable tdd and agile processes.
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.
– Hardware and software engineers traditionally spend most of their time segregated. How do do we show them the value of designing together on the same 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. ;^)
1. I am particularly interested in knowing about test frameworks that work well in a flat C embedded (headless) environment. What alternatives are available? Relative merits? Deployment curve? Hands-on experience?
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?