Copied from the Portland Pattern Repository Wiki page of the same name. There is a lot of wisdom here that could be useful in designing and writing our Avionics software.
-- IanOsgood - 19 Mar 2004
From the XP Mailing List:
Wow, tell us more, tell us EVERYTHING! --Ron Jeffries
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 Planning Game; 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, Pair Programming, 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.
Ron Morsicato (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 Charles Poole) -- http://www.cutter.com/itjournal/xp.html
There will be more articles (and possibly a book) forthcoming about Embedded XP.
-- Nancy V.
Here is a writeup of a methodology which brings Test Driven Development to the embedded world.