Sign In
Forgot Password?
Sign In | | Create Account

Agile embedded

Colin Walls

Colin Walls

Posted Dec 14, 2009
1 Comment

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.

Waterfall, Agile

More Blog Posts

About Colin Walls Follow on Twitter

Colin WallsI have over thirty years experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, I am a member of the marketing team of the Mentor Graphics Embedded Systems Division, and am based in the UK. Away from work, I have a wide range of interests including photography and trying to point my two daughters in the right direction in life. Learn more about Colin, including his go-to karaoke song and the best parts of being British: Visit The Colin Walls Blog

More Posts by Colin Walls

Comments 1

Post a Comment
We've been using various agile methods for a number of years, both in Flomerics and now in the Mentor Graphics 'Mechanical Analysis Division' for the development of FloTHERM and FloTHERM.PCB. Ignoring the actual mechanics of the process itself (SCRUM, FDD etc.) the real benefits imho are as follows: -A 'ready for release' mentality where incremental feature additions are tested, documented and accepted before the next feature or task is addressed -Not biting off more than you can chew. Breaking a feature down into a series of implementation tasks taking say no more than 3 days each enables a focus for the whole team that results in an overall improvement in quality -Visibility for all stakeholders. Breaking down the cubical and over the wall approach between the various software development disciplines, little tasks that the whole team acknowledges works on as concurrently as possible Main issues against are the inability to predict at the start of the project the exact release date but at least by looking at your feet during the process you don't trip up in your rush to reach the horizon.

Robin Bornoff
2:27 PM Dec 17, 2009

Add Your Comment

Please complete the following information to comment or sign in.

(Your email will not be published)


Online Chat