By Jack Ganssle

Deep Agile

Published 5/25/2009

In late April the Agile Bazaar (http://www.agilebazaar.org/), a Boston-based group, held an all-weekend conference about using agile methods in building embedded systems. The event sold out; about 100 attendees devoted their Saturday and Sunday to learning about various aspects of agile development.

Both Russel and James conducted a test-driven development hands-on that some 80 people participated in. Though Guinness wasn't there to confirm it, we suspect this was the largest group TDD activity in history.

Deep Agile's web site (http://www.agilebazaar.org/index.php?option=com_content&view=article&id=71:deep-agile-embedded-review&catid=34:deep-agile-embedded&Itemid=64) has a picture of James and I role-playing. I'm the CEO of a company that is frustrated with my group's software efforts and James is trying to convince me that the solution is to adopt an agile approach. He did a great job, and the audience got more than a few laughs.

In real life I remain a bit skeptical of some of the agile methods. For one, no one seems to know how to define "agile." Is it the use of continuous integration? Pair programming? 40 hour work weeks? I think we agreed that agile is as hard to define as is "embedded." One knows it when one sees it, but that fuzziness means it's all too easy to apply the "agile" word in pretty much any circumstance.

We did agree that agile is not about hacking. I see too many teams who have abandoned all pretense at discipline in the name of agile. In my experience, successful agile teams are as process-driven as those employing heavyweight traditional development models.

Perhaps my biggest problem with agile approaches is the deprecation of design. XPers proclaim "you're not gonna need it," since requirements change means today's feature is in tomorrow's dustbin. Why waste time designing something that will never make it into the product?

But in the embedded world we generally must do serious up-front design. Of course it's impossible to know everything at the outset, but we're required to make design commitments from the outset, like processor selection and memory size. Pick these wrong and your project will be a disaster. That implies a pretty good sense of what the system will be in terms of size and loading. We don't generally have a 4 GB address space, and loading up on extra memory "just in case" is expensive, and may make the product unprofitable.

The embedded world suffers from requirements changes, but not to the degree web designers do. Most of the data I see suggests we face a couple of percent change in requirements per month, or less. Compare that to the 50% or more experienced by those poor sods doing IT and web development.

Agilists get some important ideas exactly right: continuous integration, for instance, avoids the disaster of big-bang testing that uncovers problems when there's no time to recover. And their focus on test is simply brilliant. Too many of us use too little unit testing and even less integration testing. It's left to the end. The schedule slips, so what gets cut? Test.

In the end I suspect agile will go away, rather as how RISC has been subsumed into general processor design. The ideas will be incorporated into industry-standard development processes. No one will make a living marketing their agile techniques since customers just won't care. They want a product, and competitive companies will use whatever best practices exist, marketing their proven successes ("92% of our projects come in early and under budget") rather than a strategy that only a developer understands.