For novel ideas about building embedded systems (both hardware and firmware), join the 30,000+ engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. Click here to subscribe.
By Jack Ganssle
I attended Agile 2007 last week in Washington DC. This annual gathering both celebrates agile software development and teaches agilists new tricks and techniques. The conference was completely sold out, hosting something like 1200 developers.
Interestingly, the conference itself was agile. Small, intimate, rooms used round tables to encourage interaction. Every class I attended had some sort of hands-on aspect that required dialog with other attendees, usually strangers. I was impressed by the thoughtful questions and comments from the crowd, and by everyone's palpable excitement.
There wasn't a lot of gray hair to be seen.
The vast majority of attendees are IT/PC types. Only a handful of embedded folks showed up, though there were a couple of sessions dedicated specifically to the unique needs of our industry. In one participants discussed barriers to the adoption of agile methods by firmware developers. It appears (though I have no hard numbers on this) that outside of embedded agile is rapidly gaining adherents. But a recent poll conducted on this site unscientifically suggests that only 16% of embedded developers use any agile method; half of those use eXtreme Programming.
I think one uniquely-embedded bottleneck is testing. All of the agile approaches demand frequent and automated tests. But that's tough in an embedded system when hardware might not be available, and where someone has to push buttons and watch displays. Some partial and useful solutions do exist, including mocking hardware and simulation. Products exist as well: Virtutech sells rather amazing simulation environments into the embedded space, and open source programs like CATSrunner and CppUnit help mock non-existent hardware. But the use of these products requires a very different approach to building firmware than most of us use today.
Though the booth space was compact, the vendors were out in force. An astonishing number of them sell agile coaching services and/or consulting, rather than products. I had a chance to sit with both Agile Logic and SolutionsIQ, which both sometimes cater to our industry. The first primarily teaches any of a variety of agile methods to teams; the second specializes in using Scrum to create software for companies, embedded and otherwise.
I found two common themes in talking to the vendors. First, an agile approach gives management <i>visibility</i> into the project's status. Too many traditional development efforts wander for months before management realizes that the project is in peril. That's simply impossible on a properly-run agile development effort. Secondly, when something goes wrong, it's apparent early so it's possible to grasp the "steering wheel" (a phrase used by many at the conference) and steer the project back on track.
The zealotry displayed by some agile early adopters is gone. Everyone I talked to recognized that agile is not always the best way to run a project. That's a healthy development I was pleased to see.
What's your take on agile in the embedded world?