By Jack Ganssle

Beware of Programmers Carrying Screwdrivers.

Published 2/28/2002

The earliest electronic computers were analog machines, really nothing more than a collection of operational amplifiers. "Programs" as we know them did not exist; instead, users created algorithms using arrays of electronic components placed into the amps' feedback loops. Programming literally meant rewiring the machine. Only electrical engineers understood enough of the circuitry to actually use these beasts.

Except in embedded systems. Intel's 1971 invention of the microprocessor brought computers back to their roots. Suddenly computers cost little and were small enough to build into products. Despite cheap CPUs, though, keeping the overall system cost low became the new challenge for designers and programmer of these new smart products.

This is the last bastion of computing where the hardware and firmware together form a unified whole. It's often possible to reduce system costs by replacing components with smarter code, or to tune performance problems by taking the opposite tack. Our firmware works intimately with peripherals, sensors and a multitude of real-world phenomena.

Traditionally this close coupling of hardware and software meant that most embedded folks were EEs. CS majors generally didn't have the background needed to know exactly which bit to twiddle when. The typical documentation dearth meant we were all supposed to somehow figure out how things work just from the schematic. how many CS folks can do that?

But the world is changing. As the firmware grows and dwarfs hardware content perhaps EEs, especially those with the minimal software training most get, are not the ideal developers. I'm astonished that even today most EEs get essentially no training in their college years in real software engineering. Sure, they learn to code, but few graduate knowing much about configuration management, requirements analysis, methodologies, and all of the other aspects of the discipline.

Almost anyone can hack 10,000 lines of C into a reasonable product. That's quite impossible, though, when we're working on projects requiring hundreds of thousands of lines. Big code demands disciplined development, the sort that (I hope!) CS folks get, big time, in college.

Yet most firmware developers are EEs who drifted into software. That happened to me, though I've managed to keep feet in both hardware and software camps. How many of us EEs have the training for the huge projects that are coming along? My recent experiences teaching at the U of MD suggest that few do. Most new EEs still get zero exposure to true software engineering, which is astonishing when we realize that even hardware design in this world of ASICs, FPGAs, VHDL and the like is an awful lot like building code. As usual, schools lag industry.

Computer Engineering is an intermediate approach that combines training in both hardware and software. I suspect that these folks may be the ideal candidates for future firmware development.

I love working at the margins of the code and the hardware, at making tradeoffs between programming and logic design, building ISRs and manipulating devices. The best projects control something moving, whether a robot or less esoteric products. Yet specialization is setting in. The future will find fewer developers tackling entire projects, and only a handful working with bits, bytes and soldering irons. I fear that unless EEs get start getting a solid grounding in true software engineering we'll be less valuable as developers.

What do you think? Are you an EE doing firmware? Did you get a solid background in disciplined software development. and how?