Cool projects at work

I've been doing a lot of coding work at my job lately, which has largely been scratching my programming itch. So much so that I've been pretty non-involved lately in my other programming projects like Parrot and Matrixy. Some background:

The products we make at work are embedded devices that contain a number of separate processing elements. We use a smart modem device that interfaces with the GPS, communications satellite, and GPRS cellphone network for over-the-air (OTA) communication. We have a master processor component that manages the smart modem and interfaces with the sensor network. Then, we have a self-organizing wireless sensor network, which connects through another processing element to the central master. In total each system we ship, depending on configuration, can have anywhere between 1 and 18 separate controllers. Since the controllers come in a variety of makes and models, each needs to be programmed separarely with various firmware, software, and configuration files, often each needing to be loaded and managed through a separate hardware/software programming interface. It's a logistical nightmare to program these units, especially when we need to program--and test--them in bulk. Because of this complexity, there has always been a dream for a single software solution that would manage it all automatically.

That, in a nutshell, is what the tool I've been developing does. I have four primary audiences, each with different (and often conflicting) needs for the software:

1. Development Engineers. These people need reliable low-level interfaces so they can interact with the unit directly. They also need basic testing facilities to ensure that the unit is operating correctly so they can identify bugs early.
2. Test Engineers. We're a small company so there is a lot of overlap between the two, but the people doing dedicated testing tend to be distinct from the group doing primary development. These people need logging and monitoring tools, along with data extraction: Important information from the unit cannot be burried in a logfile somewhere, it needs to be extracted and presented in a clear way. When there is a problem or even a small incongruity, the testers need to be made aware of it immediately.
3. Manufacturing Engineers. These people need to be able to program and configure the units quickly, with a minimum amount of spent time and effort. They also need to be able to run quick and easy canned sanity tests to identify potential problems early in the manufacturing process. Since a majority of our assembly personel will eventually consist of unskilled manual laborers, it's imperative that the programming and testing interfaces be user-friendly and mostly automated.
4. Field Engineers. These are the people who are responsible for travelling across the country and welding our units onto the top of a train car. These people need monitoring and sanity testing capabilities, along with basic diagnostic and repair functionality. The field engineers are not all employees of our company, so they can't all be assumed to have prior training on anything we send them.

I've got a lot of automation in my program, as should be evidenced from some of the audience requirements above. Yesterday I migrated the whole program to a new unified concurrency scheduler to facilitate it all. It sounds a little bit more grandiose then it currently is: it's a basic queue structure attached to a high-granularity timer. Previously, all individual subsystems handled their own asynchronous behavior, which lead to a few different and incompatible systems.

I'm trying to relentlessly follow some of the Agile Programming lessons I've learned, especially from chromatic and the Parrot project. I refactor and improve relentlessly, I cut regular releases every 2-4 days (I only work on the program part-time, and some days I am so busy with other high-priority projects that I don't have time to cut the release), and solicit lots of feedback and bug reports from the people who are using the software. So far, I think the results have been pretty impressive and I've gotten a lot of compliments not only on the quality of the software but also on the rapidity that I've been developing it.

There are a few parts of the Agile method that I don't partake in. For instance, there is no pair programming, which makes sense when you consider that the entire development team is me. I do, however, interact in a very high-bandwidth face-to-face way with the program end users, so that helps. I also don't do a lot of unit testing, I simply haven't found a good way yet to do that in this particular application (I'm also a bit of a testing n00b, so maybe I just am not creative enough to find a good way to do the testing). All told however, I think I am definitely an Agile programmer now, and the benefits of the system to me are very apparent.