Low Country Software Ramblings

I am a big fan of Agile Development. I believe it leads to software that does what customers want (as opposed to what they ask for…not necessarily the same thing). Agile is not a silver bullet, and many gurus have expounded on this point. Agile is hard! It takes discipline and a buy in from management to implement a reasonable process. In fact, some of the tech blogosphere gods are not sold on all agile practices, but that is a debate for another forum.
Agile is becoming mainstream in the world of Web and Application development. However, in my experience, it is not used much in the embedded world. This is my feeble attempt at exploring the possible reasons.

One of the major reason embedded software tends to use Big Design Up Front (BDUF) is that the embedded software process is tied to the hardware process; and the hardware process is inherently BDUF. Hardware reworks costs can be significant. You better nail down the desired functionality early in the process. Rarely will the software team have the luxury of waiting for the hardware before starting work. Most of the time, you have parallel development. Since the hardware team follows BDUF, it is only natural that the software team follow suit.

Another reason Agile can be difficult to implement is that when you get the first hardware prototypes, you will inherently have a big bang intergration. This is the first time you see the hardware platform, and now you have to make it work. This will really set an agilist on edge. Sometimes, there are ways to mitigate this; using a commercial hardware board which ressemble the hardware platform is a favorite approach. Sometimes though, the hardware is so unique that it is not an option.

A third area of difficulty concerns the whole testing aspect; both unit and acceptance tests. I alread wrote about embedded unit testing, so lets talk about acceptance tests. I have observed that regardless of your development methodology - BDUF or Agile - with embedded devices, you need acceptance tests. In fact, you really need 2 levels of testing. The company I cut my teeth in used to have a “Design Verification” phase. This is where the hardware engineer ensures that all the bits & bobs of the hardware platform work. It might involve writing a minimal amount of code to drive a few pins, and insure that from a hardware perspective things work. This would be your first level of testing. Note that once it is performed, it is rarely revisited. The second level of testing is your typical functional/acceptance testing, where you will be performing testing the functionality of your device as a whole. From an agile perspective, the trouble is the difficulty of automating this type of testing. It could cost more to engineer a fixture to automate the testing than designing the product in the first place.

There are other reasons why Agile is not more prevalent in embedded circles, but I believe those 3 factors account much of the inertia. What do you think?

No Comments »

Eric Berger clued me in to the fact that Britain’s Royal Society has made the complete archive of its scientific journals available online.  This is a treasure trove of scientific information;  over 300 years of research is available.  We’re talking original papers by Newton, Darwin, Bohr, Faraday, Fermi, and even Leibnitz (who had a tiff with Newton about Calculus).

Quite serependitiously, I am currently reading The Baroque Cycle by Neal Stephenson.  It is set during the founding of the Royal Society and talks quite a bit about it.

Kudos to the Royal Society

No Comments »

To your average software engineer, the type of processor used to run a program does not matter. Want some proof? Look at the decision by Apple to move from the PowerPC to the Pentium. How many application developers will be affected by this decision? Not many.

These days, the underlying hardware is so abstracted that the processor type is almost irrelevant. No one working on FireFox for the Macintosh will be affected. Why should they? Just as an application does not care what the specific graphic card is, it does not care what the processor is. Most applications use the OS API, the graphic library, etc…

You want to know a dirty little secret? The same is often true of software designers working on embedded systems with 32-bit processors!

The reason is simple: 32-bit processors (80×86, PowerPC, MIPS and ARMS being the market leaders) almost invariably use an Operating System. Rarely will you do bare metal programming. Windows CE, VxWorks, Integrity, Embedded Linux (and a plethora of others) all abstract away the hardware.

If you use an off–the-shelf board, chances are the board vendor already has the Board Support Package (e.g. the low level drivers) ready for your given OS. If you have a custom embedded device you are working on, clearly someone will have to write the BPS.

But let’s face it, writing yet another ethernet chip driver is not where the value added portion is. It’s in the application! That is what most of your engineers will be working on. And to (most of) them, it’s just another software program. It simply resides in a funny box without a keyboard or screen.

No Comments »

Argh! I was all pumped to start playing with PowerShell, downloaded RC1 and launched the installer. Standard dialogs pop-up, all is good. Let’s start the install and…woah!

Windows PowerShell Setup Interrupted

What is going on here? We’ll try it tomorrow on a test Virtual Machine and see if we have better luck. I was looking forward to exploring the cmdlets!

No Comments »

I went to our local RadioShack today and it it me. The electronic hobbyist is no more. There are a time when one could walk into a RadioShack and purchase components to build all sorts of fun electronic circuis. These days, you would be hard pressed to find anything other than a few resistors. It is all about consumer electronics. Those of us who grew up with TRS-80 and Apple ][ are the last generation to experience electronics as a hobby.

Today, it is actually easier than ever to build an electronic circuit. The software to do schematics capture and generate the circuit board is free. You can order circuit boards over the internet for $50! A few days later, you have a professional quality PC board. The components are widely available from distributors like Mouser Electronics and Digi-Key.

I believe the death knell of the electronic hobbyist was the advent of the personal computer. While computers expanded what one could do with electronic circuits (Robotics, data gathering, Lego MindStorm), the fact that you can now create something cool by simply typing is a compeling proposition.

Take your technically minded teenager. In a few minutes, he can create a program that does something! Even if it is just a simple “Hello World!” from a book, it is still a rush! Contrast that with the building of an electronic circuit. You have to have the parts, wire the things up, and after fiddling for half an hour, you have a blinking light. Meanwhile, your computer friend is on his 3rd program, poping up dialog windows. Remember, with teenagers, it’s all about instant gratification.

More than just nostalgia, there are some practical implications to this: Could we have another Woz today? How about an Earl Bakken, which literally saved lives with his garage invention? Could a pair of Hewlett and Packard be possible in today’s climate? Certainly, the garage inventors are still alive: Larry and Sergey are a prime example. But like them, they are more than likely working on a software widget. Where will tomorrows hardware come from?

1 Comment »