6

I have had great success e.g. with fast development cycles and continuous integration.

However, I think pair programming or continuous customer communication are less useful due to issues specific of embedded software programming.

What do you think? What are the most useful agile practices on embedded software development?

Solano
  • 63
  • 4
  • 1
    Can you give examples of what it is about embedded software development that makes either of the practices you mentioned less useful? – JeffH Dec 21 '10 at 16:04
  • Perhaps it is due to the specifics of roles I have worked on, but I've always found that different engineers are specialized e.g. on different HW subsystems. I found it is not that easy to collaborate on a piece of code as only one of the engineers knows the affected HW in detail, which is an issue specific to the embedded world. Also, I think that in embedded systems customers don't have so much knowledge about the inner working of the SW as in application SW and this makes it less useful to have constant customer communication. Of course this is just a generalization. – Solano Dec 21 '10 at 18:33

3 Answers3

5

I would have to disagree. I've done it, and about 10 years ago I co-founded an agile coaching company specializing in embedded (we're no longer a company but the website is still up with several useful resources). I recently helped another company adopt agile for their embedded project, and it worked very well for them.

Agile practices like short iterations, pair programming, and frequent communication with the customer are even more important with embedded software because there's more at stake, both because embedded systems are usually harder/more expensive to update in the field, and because they are often used in mission-critical applications.

As for pair programming, if your company only has one person that knows the first thing about a component of the software, that's a huge risk, and pair programming is a great way of doing cheap knowledge transfer. Both developers don't have to be experts in that part of the code. You can have a primary that is and a secondary who isn't. The secondary partner is able to offer help on program structure, compare design decisions, ensure proper testing and documentation, etc. Of course each developer has to be a primary sometimes and secondary other times to make the crosstraining effective. This is also a very effective way of bringing new developers up to speed on your products.

Lastly, customers care about features and plans, not code. Embedded doesn't change this. Showing off what you have so far and what you plan to do next ensures you're working on what you're supposed to.

dj_segfault
  • 11,957
  • 4
  • 29
  • 37
3

Embedded software development is no different then normal software development, therefore you can use every agile practice you find useful.

Concerning pair programming, I look at it as a code review on steroids. If your company can afford enough SW engineers, I don't see a reason why it could not be used for embedded software development.

by the way, what exactly do you consider under "issues specific of embedded software programming"? I do not have experience in non-embedded software development, and I do not see how it could be different.

BЈовић
  • 62,405
  • 41
  • 173
  • 273
  • Adding to my comment above, I feel that the scope of embedded software is somehow broader than e.g. application software. All software is complex, but additionally embedded software often requires expertise on issues concerning real-time behaviour, interaction with external events, interfacing to hardware, detailed hardware knowledge, etc., which means that it is difficult for two engineers to know well enough the same part of the system to be able to do pair programming. Of course theoretically a company could hire enough engineers to avoid this but in practice it doesn't happen. – Solano Dec 27 '10 at 00:06
  • @Solano The HW is most likely custom made, therefore two or more engineers can easily learn how to access such hardware. RT is probably the only thing specific for embedded development. – BЈовић Dec 27 '10 at 12:29
0

It is not obvious to me the value of Agile in many applications.

Many applications, including embedded applications, often include standards based protocols or technologies. You download or buy the specification, you implement the specification, testing as you go, and then you are done. What would I do at my daily standup, "Um, today I read pages 1 through 9 of the standard, tomorrow I plan to read pages 10 through 17". How does standards based development benefit from Agile? Quick response to changing customer input, um, no. The standard doesn't change from day to day.

If Agile software really means "training" then paired programming fits. As pointed out above unless you can afford exactly double the number of engineers it is likely you will have different specific skill sets among your engineers. In a large organization with many engineers with overlapping duplicate skills maybe you can pair engineers efficiently. In a smaller organization how does that work? Unless it is actually paired training, then ok. Sounds expensive though.

Often a huge amount of infrastructure is required just to host or deploy the smallest amount of first pass functionality. How might I do test driven development for an embedded flight controller, or automotive engine controller? Years of effort are required just to get the infrastructure in place to host a test. I certainly don't want the rest of my designers and engineers sitting around idle waiting for the test infrastructure so they can do TDD. I need standards driven development while waiting for many of the pieces to come together.

brad
  • 11