Embedded Extreme Programming

Has anyone given thought to how XP applies to EmbeddedSoftware? Some of the potential collisions I see between XP and conventional embedded design:

Typically there's only a couple of "user stories": "Data enters hopper A, and then [omit 17 pages of operations performed on the data] ...and finally data exits spigot Z".
Customers, and management, expect (and frequently specify in the contract) that several months will be spent in design before coding ever starts. Once coding does start, it is expected that detailed specifications and pseudocode will exist for every single class and method in the system. Coding then becomes essentially a fill-in-the-blanks proposition.
Usually there is no possibility of using a garbage-collected, dynamically-bound language. Speed is paramount; and the requirement for any given function to have a constant execution time nixes the possibility of a garbage collector. In some cases even dynamic memory allocation (off the heap) is out of the question because of hardware limitations. (RealTime systems)
Management still views newfangled ideas like ObjectOriented design as suspect.
UnitTesting is made difficult by the fact that the stubs frequently grow larger than the units they are create to test. For example, to properly exercise an IO class, a stub has to be created to generate valid sequences of legacy messages, each message being a struct with several hundred fields.
Embedded systems often have strict (RealTime) timing and throughput requirements, especially in interrupt handlers, and these requirements are, of course, most stressed when the system is fully loaded, not during programmer testing. XP doesn't really help you meet those requirements.
Embedded systems are expected to run for years. Object and memory leaks must be avoided, and XP doesn't really help you meet those requirements.

This is the world I work in, and I've been wondering what elements of XP are applicable to such a world; and how one would go about introducing them (especially when one is extremely junior...)

What I have seen in college, from a professor who used a little bit of XP on my embedded communications systems course, is that some practices of XP can be worked into the embedded development cycle. For example, we did quite a bit of unit test-driven development, we would always work in pairs, code ownership was collective among all classmates, coding conventions were followed strictly, and our professor (who acted as our customer) was always on-site. (There was no planning game though because being this an academic course, all the requirements were already laid out and everything was pre-planned).

We did, however, had to document a LOT. The professor would make us turn in a lab report for every assignment we did. Sometimes we actually took the entire class to plan what we were going to do and set up our goals for the next milestone. We would sperg a lot on our designs and that was basically why we never actually used for-reals XP.

-- DaNuke?

The big problems that sparked XP are probably not the biggest problems in embedded programming. Many if not most embedded software projects are smallish, don't suffer from runaway requirements; and, because the environment is dictated by cheap hardware, the temptation of programmers to add stuff that isn't needed is small. I know there are exceptions: telecom switches, often considered embedded, are pretty complex and run on fast processors.

Having said that, there are many XP practices that embedded developers could benefit from. --AndrewQueisser

A big knock against XP would is do the simplest thing that could possibly work. There's often enormous hardware related design efforts that have years lead time which require a rather deep dive into requirements and implementation.

From the XpMailingList:

Wow, tell us more, tell us EVERYTHING! --RonJeffries

That's a tall order. I'll tell you almost EVERYTHING and let you ask further about the areas that interest you. First, I want to thank you, Ron - I attended your XP talk at SD west in spring of 2000, and that's when I turned on to XP.

In 1999 I got my EmbeddedSoftware project staffed at a large company in the Boston area. At the time I knew nothing of XP, but I was determined to apply good practices I'd picked up in the school of hard knocks, as they call it. I instituted strong unit tests for each module, coding standards, source code management, common code ownership, frequent code reviews (more as knowledge sharing than as a police action), solid build control, and iterative development. I was also very conscious of good naming & shared design concepts - i.e. we were using what XP calls 'metaphor'.

This all worked quite well. We didn't have anything like the PlanningGame; I just tried to figure out what should go in each release and get them out as regularly as I could. I was doing most of the estimating but I wanted the others to learn how. Our bug rates were very low - about 1 bug per 2000 lines of code. Bugs were tallied at integration test, not unit test.

The team started as 5 members, and varied between 4 and 7 members at times. I don't mean to make it sound like it was easy. We "fell off the wagon" a couple times and it was tough to get back on, but we did. Initially there was no management support for XP - there was even some hostility. It took us about 3 months to get our first release done (new board, new CPU, new Flash, tools to configure, new staff coming on at intervals) but once we began delivering usable code at regular intervals, management was impressed.

In spring 2000, I found out about XP and later we tried the Planning Game, PairProgramming, and made more effort at 40-hour week. We worked for smaller releases, and were glad to see Refactoring brought out of the closet (we'd been doing it but feeling guilty because it didn't add features). Our bug rate stayed low - at the very same level in fact. But our releases became much more regular and all the developers learned to estimate.

The key practices we added to deal with the embedded realities were:

Leave a bread crumb trail - a trouble log that is always "on" so it doesn't distort your troubleshooting by having to be enabled.
Dual targetting. Make your app run on a desktop as well as on the target CPU to isolate board-specific problems.
Stand-alone module execution. Each loosely-coupled domain of the app should build and execute alone on either target.

The above 3 practices allowed us to cut through the toughest bugs like a chainsaw! They are incredibly powerful especially when used together. At the start of the project, 3 of the team members had no experience with real-time or embedded software. The team practices had the effect of putting a safety net under everyone, so they could learn without getting hopelessly tripped up (or wrecking the code). I also taught them all I knew about multitasking - another skill that was absent from all the staff except me. The funny thing is that the worst multitasking problem we had was a deadlock that held us up for a few hours, and it was my bug.

RonMorsicato? (a team member) and I wrote an article for Cutter's IT Journal last year about our experience. Here's a link (it was mentioned in a previous posting by CharlesPoole?) -- http://www.cutter.com/itjournal/xp.html DeadLink as of 28 Nov 2007

There will be more articles (and possibly a book) forthcoming about Embedded XP.

-- Nancy V.

"Extreme programming without fear" article by Dan Pierce Embedded Systems Programming 2004-02-05 "Is XP suitable for embedded systems programming?" http://embedded.com/showArticle.jhtml?articleID=17602057

EmbeddedSystem ExtremeProgrammingBareMachine CategoryRealTime