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 a while ago 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, reduced execution speed or excessive power consumption 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. I would be interested to hear about your experiences with Agile by comment or by email.

Colin’s most recent publication, Embedded Software: The Works is available now on the Elsevier Store. Save 30% on his book and other Newnes Press and embedded systems books. Use discount code “SAVE3013″ at checkout. 

About the Author

Colin Walls (@Colin_Walls) is an embedded software technologist at Mentor Graphics (@mentor_graphics), the leading EDA software company.

You can read more about Colin and his work on embedded systems at The Colin Walls Blog at Mentor Graphics here. Connect with Colin online here: