Search

Saturday, March 09, 2013

Agile in Embedded Software Development


In my spare time, I build various small devices using Arduino hardware or help my sons create small games.  I enjoy building devices because I had a background in hardware development as well as software development before I became a full-time game developer 20 years ago.

Embedded development benefits as much from agile practices as pure-software development.  I recently shared some tips on some of those:

  • Find ways to iterate the hardware as well as the software.  We found that reducing the time between software and bring-up paid dividends despite the cost of additional hardware development.  More breadboarding/prototyping was a big benefit.
  • Find ways to implement unit testing of the hardware as it's brought up and incrementally improved.  Using an example device that controls a lights brightness:  have a test that would send brightness commands to the hardware and allow someone to verify that the hardware is performing as expected at each level.  Automation of this is nice, but not always possible.
  • Find ways to ensure that interfaces are established, communicated and, if changed, easily and quickly communicated between hardware and software developers.  This is usually not a big problem on small teams, but it is with larger teams.  So, for example, if hardware changes the brightness control from an analog interface to a digital one, the change is reflected in the code and tested quickly.
  • Encourage hardware and software engineers to overlap as much as possible.  I like the phrase "generalizing specialists".  One tip: don't play paintball as a team building exercise.  We did that.   The hardware engineers teamed up, figured out how to increase the shot velocity of their paintball markers, and gave all of us software engineers painful welts.  It wasn't a good team building exercise. ;)
  • If you have any sensors, motor controls, transmitters, receivers, etc that have to interface with the real, noisy world, try to test these as subsystems as early as possible in the target environment.  One time we went out to sea on the first test of an underwater modem which we had simulated in Matlab and an enclosed water tank.  The temperature inversion layer, multi-path and Doppler effects of the actual ocean environment demonstrated that we were very much farther away from completion than we thought.  It was a bad day.


No comments: