Embedded Software Development Economics 1

A Java developer of my acquaintance once remarked, probably to his eventual regret, "I don't want to know how it works under the hood." I've made a lot of filthy lucre off this attitude in others, so I have a strong economic incentive to encourage it. But in fact, I believe that to control costs in development projects you have to have developers work at as high a level of abstraction as possible. This is why we all don't still work in assembler except when it's really necessary.

This is also why I really like Linux/GNU as an embedded platform when it's possible because it opens the possibility of doing a lot of development for prototyping or even production in scripting languages in which the think-type-compile-debug cycle can be very very short. I've leveraged the hell out of the bash shell, or even the more limited BusyBox ash shell, on embedded products. Scripting may also allow you to use less expensive developers who have no idea what the sizes are of variables in memory, but don't need to know for the kind work that they do.

(Update 2012-02-04: I've also made excellent use of the command line shell available in the VxWorks RTOS that allows you to invoke any function with C-linkage and pass it integer arguments. I have implemented a similar capability using Ficl, a full blown Forth interpreter, embedded in a C++ application. The latter is fully doable in a non-Linux/GNU or even non-POSIX system, including those systems which run from flash or are completely memory resident.)

Java falls into this category. If you can support it on your system, and its footprint meets your resource requirements, then you would be remiss not doing as much work in it as you can, with faster development iterations and less expensive developers. Java is increasingly becoming the language of choice in which to teach software development, so more and more college graduates are being produced with Java as their core programming language competency. I'm fully aware of the irony of this since some of my buddies tell me that Java is on the wane as an application language. But I think it has a lot of merit as a high level embedded language. Case in point: Android, on its way to becoming the most popular software platform for mobile devices, which has a Java application layer sitting on top of a C/C++ run-time and Linux kernel.

Over the years I have personally helped develop and ship two Java-based products. One was a typical server-side application than ran on powerful multi-core Pentium boxes. But the other was a small embedded system that was based on a PowerPC microprocessor running a real-time OS and for which I developed device drivers in C and the application, some of which had hard real-time constraints, in Java. The Java development went a lot faster, in part because we could develop and test a lot of the application on our desktop in simulation using VisualAge, the IDE which eventually evolved into Eclipse, along with all its editing, refactoring, and debugging capabilities.

Those organizations who insist on doing everything in C or even C++ when more cost effective alternatives are available are quickly going to go the way of organizations who want to do everything in assembler on gigahertz ARM processors. Which is to say: they won't exist.