Agile embedded
The Agile methodology has been talked about for some years. To be frank, I have given the matter very little attention – I just had a basic idea of what it was all about. I suppose I had a feeling that the approach was rather chaotic and disorganized, which is at odds with my view of what programming should be like. However, I attended a talk at a conference recently which changed my mind. The presenter was, in essence, trying to sell some project management tools that support the Agile methodology. But he also described the philosophy in terms that I could appreciate. I realized that what was being proposed was very similar to the approach that I have espoused for many years …
Broadly speaking, Agile is an alternative to the traditional “waterfall” methodology, where development proceeds through a design phase, then coding and lastly debug and testing. With Agile, the process is accelerated. The project is progressed as a series of short cycles – typically 2 weeks duration. At the end of each cycle, working software is delivered. Each delivery includes bug fixes and additional functionality.
There are two separate reasons why I believe this may make sense for many embedded projects:
Firstly, embedded devices are often black boxes. They have plenty of internal functionality, but little, if any, is immediately visible from the outside world. This contrasts with desktop software, most of which has some kind of user interface. I have always felt that there is a psychological benefit to be gained by getting a system to show signs of life as early as possible. With Agile, you need to deliver working software, so it is logical to include some interaction with the world to make that functionality manifest. This might mean producing some result on a display, flashing some lights or responding to a communications interface.
Second, embedded systems always have some kind of limitation on resources – typically both memory and CPU power are bounded in some way. However, most systems have performance criteria that need to be met. With the “waterfall” approach, a shortage of memory or reduced execution speed may not be apparent until very near the end of the project. With Agile, as functionality is added incrementally, the use of resources can be carefully monitored. If there is a sudden increase in memory usage, for example, its cause can immediately be identified.
Clearly the Agile movement has gained a lot of supporters in recent years and I suspect that support is very strong in the embedded community. This is a topic to which I am sure that I will return. I would be interested to hear about your experiences with Agile by comment or email.
