Why not start Saturday with a rant? Not an ordinary rant though – this one is about the way people write software, in particular the class of software that I come into contact with more than any other: embedded device software.

I have concluded that there are different classes of people writing this kind of software professionally. The three I most commonly encounter are:

1. Software Engineers
2. Computer Scientists
3. Hardware Engineers

Each of the three has a place in the software food chain, but it is important to understand where that place is, and what limitations they have due to their background & training.

For example, a person trained as a computer scientist will tend to focus on the elegance of the algorithm. A software engineer will be looking more at how to take an algorithm (or more likely a number of them) and produce an efficient, reliable and maintainable application from it. Hardware engineers seem just throw something together with little care about the algorithm or the quality of the implementation (“as long as it works what’s the problem?”).

So, where do they all fit in the food chain of software? I would like to draw a parallel with other kinds of science & engineering here. In a research laboratory one would generally look to employ top notch scientists to concentrate on new ideas and concepts. I would expect computer scientists to end up in the same kind of role for software. Engineers, of whatever discipline, take the results of the research and apply some specific real-world experience to it to make products that people can rely on. Whether it is bridges, electronic devices or software, the same basic expectation is present: it must work, and keep working. Unlike a research lab. where failure is expected some of the time, in the real world that is usually unacceptable.

What about hardware engineers? Well, to be frank, they just don’t belong in the software food chain. That’s not to say that they shouldn’t be writing software, just that none of the software they write should ever leave the confines of their workspaces. It is odd that a group of people who are so precise and careful with hardware designs (they are engineers after all!), are generally so bad at writing software. I can only put it down to a lack of training.

How can one identify members of each class? Well, there are some tell-tale signs in the code they write (again, these are broad generalisations, so expect exceptions to show up from time to time):

• Computer scientists seem to avoid comments, rely heavily on language and compiler features, and rarely worry about validation of parameters or error conditions (and when they do, they normally handle it by aborting everything). Alignment, endianess and other ‘hardware-specific’ aspects are just not on their list of concerns (“doesn’t the compiler handle that?”).
• Hardware engineers might write comments, but not often. They may test for error conditions, but inconsistently, and they will probably abort rather than handling the error in the application. They also tend to ignore indentation, remove as much white space as possible, and will have a tendency to just throw something together first, then make it work afterwards, if possible.
• A software engineer will tend to work out a design, at least in their head if not written down, will have a defined error handling mechanism for everything, and will avoid the use of ‘clever’ language features and compiler options that might not be understood by everyone, or portable to other systems. The better ones will write code defensively to prevent future maintainers from making mistakes as well (such as always using braces even when there’s only one line in the block, or using parentheses to make the order of expression evaluation clear). Comments will be everywhere, and whitespace will be used to improve readability. Expect to see support for endianess, and care taken with the likes of structure alignment and packing.

Is it really that black & white? No, of course not. There are numerous people who were trained in one of the three disciplines but have managed to cross over successfully. Unfortunately, there are just as many who think they have done so, but really just continue to write software the way they always have.

Many good software engineers studied Computer Science at university, so it is not as simple as looking at the title of the training course they followed. Depending on the university, CS may be a very ‘pure’ course (e.g. Cambridge in the UK) or perhaps a more practical one. There are also courses with names like Computer Systems Engineering, or just Computer Engineering, at many universities now.

How am I qualified to make this rant? Well, if I need to be qualified to rant about something, I think that my Bachelor of Engineering – BEng (Hons) – degree in Computer Systems Engineering from the University of Kent, at Canterbury, UK would be a good start. Then I am also a Member of the Institute of Electrical Engineers and a Chartered Engineer. Finally, I’ve been working with software for embedded systems (ranging from military systems that cannot crash, ever, to consumer devices that people do not see as computers, so do not expect to have to reboot) for over ten years now.

Been working (as in work-related working) on something rather odd today – replacing the Linux software that comes pre-installed on the Linksys WRT54G home gateway box with VxWorks for a reference platform to send out. Normally when I’m hacking these commercial systems for use as reference platforms and/or eval systems it is either the other way around (replacing VxWorks with Linux), or just replacing the Linux system that is already there.

There’s a lot of information about hacking this platform available on the web, but perhaps the most useful pages were the Seattle Wireless group’s WRT54G page and the WRT54G Single-port Serial Modification page. My small collection of version 2 WRT54G units now have front panel mounted 9-pin D-type connectors.

One odd thing about all of this is that all of the version 2 units came in boxes labelled version 1.1. Don’t know how these guys keep track of the different versions! Comparing the box to a real version 1.1, there is a subtle difference: the real version 1.1 does not have the Wi-Fi 802.11g certification box checked.

Not much to report from this year’s embedded systems conference really – there was nothing that really leapt out as significant. I did manage to snap a few photos though:

Notice the huge amount of empty space at the Wind River booth. Not sure what they were trying to achieve, but I heard many more negative comments about it than positive ones. The best one was the quip that they had simply “increased the footprint and reduced the content.”

Giveaways were certainly much harder to get this year – and I didn’t see any t-shirts at all (though I did hear that one place did have them). The place did seem busier than last year though which might be a positive sign for the embedded industry.

Motorola has a couple of Linux based smartphones: A760 and A768. Check out the photos of the latest model, only available in China at the moment, on the excellent LinuxDevices website – a must-read for anybody interested in embedded Linux.

Motorola is not alone either, an earlier story on the same site describes NEC’s 3G Linux-based phone.

Of course, to put this in context, these phones are hardly low end devices. According to this article about the Motorola A768, it has 96MB of RAM. That’s more than I had in my desktop PC just few years ago. Still, these phones should prove that Linux can certainly fit into places where PocketPC and PalmOS can go, and bring all the advantages of a relatively robust process model OS.