One of the cool aspects of doing Mobile systems is that you often get to do a different kind of programming. There are plenty of business problems to solve with ASP.NET and SQL but I've recently had a very cool opportunity.
A local company is in the fleet fueling business, this means if you are, say, FedEx in Atlanta, they bring fuel trucks around to your lot at night and re-fuel all your Coca Cola delivery trucks. The fuel is dispensed using control systems in the truck comprised of fuel meters, printers, and other devices. As you can imagine with oil-based products being very expensive right now, there are a lot of fraud-prevention mechanisms and business rules related to fuel pricing. I recently completed, and am now supporting in Production, a new Compact Framework based application that controls the control systems on the truck. There were many cool-yet-annoying requirements on this effort that forced me to defend-or-change some of my software engineering practices: they system has to talk to several different brands of fuel meters to record gallons, meter totalizers, preset delivery amounts, etc. Each manufacturer has its own protocol and there are no well published APIs or Web Services: binary hex instead. We also could not be tied to any specific make/model for any of our other hardware: PDAs, wireless to serial bridges, port replicators, CDMA modems, mobile printers. Supporting Windows Mobile 2003 and raw CE.NET 4.2 on the same codebase along with 4 different flavors of different OEMs' barcode scanners, cold boot procedures, and WiFi registry settings was also a "Lesson in configurability".
Here's a shot of my oh-so-clean and ergonomic development environment with various handheld units:
The most excellent part of this system was interacting with the hardware on a real truck once everything was working. One great thing about being a developer is changing code and then seeing it dance on the screen; pressing a button to calibrate a Fuel Meter, writing exception handling code that tells hardware to reboot itself, scanning a barcode and then watching Low Sulpher Diesel flow out of a real truck at a pre-determined flow rate, now that's fun, and realy damn cool. I recall a conversation with one great architect who was telling me about his experiences with writing warehouse control code many years ago. He said words to the effect of "Design and testing take on new meaning when a 'bug' results in boxes piling up somewhere or flying off the end of a conveyor belt with nothing there to catch them." Working in the hardware world occasionally helps make code and the things the code does more real. If you ever get a chance to work with a hardware system, don't pass it up, you'll probably be thinking and talking about it for a long time. I'll never forget my first hardware control system experience working for a local manufacturer. We had a large "test bench" setup so that we could watch lights blink. One aspect of the software we wrote was the notion of an Alarm that would occur on a client application if hardware operating parameters were outside norms. The canonical alarm example was that a processor could overheat. While we stood around deciding how we could accurately test a real alarm situation, one of the testers pried the heatsync off of said processor with a pocketknife to create the alarm state. Contrast that with the types of testing we normally see on projects, "If I leave this field blank, it doesn't save" and things like that.
Speaking of test benches, here is a shot of some of my test hardware:
All in all, this is one of the coolest projects I've gotten to work on. I'll ask for permission to post pictures of the actual fuel trucks. Now I just have to convince them to upgrade to CF2 and SQL Mobile...