Test Driven Development for Embedded C. J. W. Grenning

 I was first exposed to Test-Driven Development at the first Extreme Programming Immersion1 in 1999. At the time, I was working on a team creating an embedded communications system. We had just begun extracting use cases from the project’s requirements document when I took a week away from the client to attend Immersion. It changed my professional life. I had discovered Test-Driven Development (among other things). As with many embedded development efforts, having a product release held up by software development was nothing new. But we could not start, because the hardware and OS were not decided on or ready. Each day added to the overall schedule. We were set up, again, because the target hardware bottleneck choked progress to a slow drip. What else could we do but have meetings, talk, argue, dream, and document the software we might write? As it turns out, plenty. Every embedded developer has experienced the target hardware bottleneck. Often the hardware is developed alongside the software and unavailable for much of the development cycle. If that’s not bad enough, both the hardware and the software have bugs, and it’s not always clear where they are. For others, the target hardware is so expensive that there’s no way for each developer to have their own target system, ready when they are. Developers have to wait, and waiting is expensive.