For novel ideas about building embedded systems (both hardware and firmware), join the 30,000+ engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. Click here to subscribe.
By Jack Ganssle
Programmer or Engineer?
I hate the word "programmer," though admit often using it as it's so ingrained in our culture. It's sort of like that four letter word that slips out despite repeated but ineffective efforts to clean up one's language.
Dictionary.com defines "programmer" as "a person who writes computer programs; a person who programs a device, esp. a computer."
A programmer is one who writes programs. That's subtly like "coder," a person who cranks code out all day. Coders, like technicians and janitors are vitally needed employees. But they can be devastating to software projects.
One of my top ten reasons software projects fail is when teams don't resist the urge to start coding. Coding is just one part of the field of software engineering, one that's similar to paving a bridge deck. Without the pavement none of us will drive, but bridge construction requires careful engineering, zoning, funding and a host of other activities far more complex than paving, and far more important to the final result. Bad pavement can be replaced or patched, but a badly designed bridge will collapse. Bad software engineering insures a project will fail no matter how well the coders - the programmers - do their job.
Most of us are engineers: software engineers, firmware engineers, or hardware/software engineers, no matter what degree we earned. In fact, in a recent poll (http://embedded.com/pollArchives/showPoll.jhtml?surveyno=257401002) only 13% of respondents claimed only a computer science degree; 80% have a sheepskin with an engineering title (EE or CE).
Engineering is the art of solving problems, which is what building firmware is all about. It starts with creating a framework within which we can think through a design - a spec, a team, a toolchain, and an approach to creating a solution. From there we design, with the emphasis on "design," a strong foundation. OS or no OS? Partition into multiple processors? How will we decompose the problem into manageable chunks? What data structures make sense?
Only then does coding start, and in some cases coding gets sent to another organization, perhaps offshore.
Coding is relatively easy; software engineering is hard. Software engineers are professionals with the hard task of building reliable systems in a reasonably repeatable way.