Over a Half Million Embedded Developers Behind On Their Learning, well not all of them.
There are a lot of embedded developers out there. Many have somewhat stale skills and a lot of challenging work to do. Many embedded software development organizations keep doing the same thing over and over again and expect different results.
In an article by Wayne Wolf in IEEE Computer[1], Wayne tells us that there are over a half a million embedded programmers. That is a lot of people writing code for the computers buried inside of all the gadgets we use. Wayne has some other interesting things to tell us. Software is taking the place of the mechanical controls of the 18th and 19th centuries and the electronic controls of the 19th and 20th centuries. Cars may have from 40 to 100 microprocessors running all the major functions of the car.
Embedded software provides an interesting layer with many challenges. The embedded software must bridge the gap between the underlying hardware implementations and the deliveries of the features the end users are paying for. Embedded developers must be competent in the inner working of the hardware, mastering part of the solution domain, as well as building applications that solve the end users problem.
Wayne also tells us “Because embedded systems programming requires juggling so many different requirements and constraints, lifelong learning is required.”
Many embedded developers don’t make the time to upgrade their skills. I see developers anxious to get off front line development into marketing or management to avoid the unrealistic demands of embedded software development. Organizations reward leaving the craft, senior engineers say “I’m a level C6, so now I don’t have to code any more.” There goes a lot of experience and expertise down the tube. Organizations need to keep people in technology. Individuals and organizations have to invest in skills.
Many embedded developers reached their current positions via electrical engineering. One of my friends told me the definition of embedded software. “Software written by EEs”. I studied EE so I can tell the joke. Designing circuits does not mean you know all about software. Design techniques and practices keep evolving.
There are advancements in software development the embedded community needs to learn and take advantage of. Object Orientation is a very important batch of design ideas. Do embedded developers have this technology down?
Jack Ganssle [2] ran an non-scientific survey from the embedded.com website asking: "Please select all of the features of object-oriented programming (OOP) that you are personally using on your current embedded programming project." The 659 respondents replied:
34.7% Encapsulation
22.2% Inheritance
14.5% Polymorphism
63.7% None of the above
This is pretty telling. A two-thirds majority don’t use any of the OO features. OO has been around since the 60 and popularized with C++ and Java in the 80s and 90s. Those using it mostly ignore its most important feature: polymorphism. C programmers should at least be practicing some encapsulation, but few adopt that coding style.
It’s not much better in the desktop and web programming areas. Many of the java programs I see could be written in FORTRAN and have the same basic unmaintainable structure.
It sounds like there is no end in sight for embedded programming either. An article in RTC projects that there will be over 1 trillion devices communicating machine to machine by 2010[3]. About half of them will be RFIDs. Of the other 500 billion will be some sort of Microprocessor. Of all this silicon a mere 300 million of these communicating devices are personal computers, one billion are phones and PDAs. A couple more billion will be in other smart devices.
Embedded developers have their work cut out for them. We better be up on the latest.
[1] Wolf, Wayne, A Half a Million Strong at Least, IEEE Computer, Sept 2006
[2] http://www.embedded.com/showArticle.jhtml?articleID=192202496
[3] Burckle, Bob and Pazol, Steve, Embedded Revolution, RTC, June 2006
!commentForm
There are a lot of embedded developers out there. Many have somewhat stale skills and a lot of challenging work to do. Many embedded software development organizations keep doing the same thing over and over again and expect different results.
In an article by Wayne Wolf in IEEE Computer[1], Wayne tells us that there are over a half a million embedded programmers. That is a lot of people writing code for the computers buried inside of all the gadgets we use. Wayne has some other interesting things to tell us. Software is taking the place of the mechanical controls of the 18th and 19th centuries and the electronic controls of the 19th and 20th centuries. Cars may have from 40 to 100 microprocessors running all the major functions of the car.
Embedded software provides an interesting layer with many challenges. The embedded software must bridge the gap between the underlying hardware implementations and the deliveries of the features the end users are paying for. Embedded developers must be competent in the inner working of the hardware, mastering part of the solution domain, as well as building applications that solve the end users problem.
Wayne also tells us “Because embedded systems programming requires juggling so many different requirements and constraints, lifelong learning is required.”
Many embedded developers don’t make the time to upgrade their skills. I see developers anxious to get off front line development into marketing or management to avoid the unrealistic demands of embedded software development. Organizations reward leaving the craft, senior engineers say “I’m a level C6, so now I don’t have to code any more.” There goes a lot of experience and expertise down the tube. Organizations need to keep people in technology. Individuals and organizations have to invest in skills.
Many embedded developers reached their current positions via electrical engineering. One of my friends told me the definition of embedded software. “Software written by EEs”. I studied EE so I can tell the joke. Designing circuits does not mean you know all about software. Design techniques and practices keep evolving.
There are advancements in software development the embedded community needs to learn and take advantage of. Object Orientation is a very important batch of design ideas. Do embedded developers have this technology down?
Jack Ganssle [2] ran an non-scientific survey from the embedded.com website asking: "Please select all of the features of object-oriented programming (OOP) that you are personally using on your current embedded programming project." The 659 respondents replied:
34.7% Encapsulation
22.2% Inheritance
14.5% Polymorphism
63.7% None of the above
This is pretty telling. A two-thirds majority don’t use any of the OO features. OO has been around since the 60 and popularized with C++ and Java in the 80s and 90s. Those using it mostly ignore its most important feature: polymorphism. C programmers should at least be practicing some encapsulation, but few adopt that coding style.
It’s not much better in the desktop and web programming areas. Many of the java programs I see could be written in FORTRAN and have the same basic unmaintainable structure.
It sounds like there is no end in sight for embedded programming either. An article in RTC projects that there will be over 1 trillion devices communicating machine to machine by 2010[3]. About half of them will be RFIDs. Of the other 500 billion will be some sort of Microprocessor. Of all this silicon a mere 300 million of these communicating devices are personal computers, one billion are phones and PDAs. A couple more billion will be in other smart devices.
Embedded developers have their work cut out for them. We better be up on the latest.
[1] Wolf, Wayne, A Half a Million Strong at Least, IEEE Computer, Sept 2006
[2] http://www.embedded.com/showArticle.jhtml?articleID=192202496
[3] Burckle, Bob and Pazol, Steve, Embedded Revolution, RTC, June 2006
!commentForm
I was a Physicist, so I started out doing embedded programming, too... ;) I always started my design documents with "Assume a spherical automobile...."
On a serious note, I'm surprised how insular the thinking can be in the embedded space, driven in large part by obsessive concerns about performance. Often, innovations are simply ignored for years because of the perception, not necessarily backed by any facts, that the performance won't be adequate. The result is low productivity of the development team stuck with older technologies and the high stress that results when they try to meet stringent project deadlines.
On a serious note, I'm surprised how insular the thinking can be in the embedded space, driven in large part by obsessive concerns about performance. Often, innovations are simply ignored for years because of the perception, not necessarily backed by any facts, that the performance won't be adequate. The result is low productivity of the development team stuck with older technologies and the high stress that results when they try to meet stringent project deadlines.
I'm kind of glad that the people who are building the software embedded in my various systems (cars, microwaves, medical equipment, photocopiers, cell phones, etc) are essentially conservative. I'm glad that they are concerned with fitting into the device and leaving a little room for patches. More power to you, guys! I'm happy also that they avoid all misuses of inheritance. To their credit, a lot of them have only moved to C++ because of a top-down mandate (a sure-fire way to get people to fake compliance) instead of a grass-roots movement. I see a lot of evidence that top-down is the worst way to sell even a very good idea to a developer community. They may have preferred to use something else (PLM, Pascal, Modula, Forth, Ladder Logic <grin>, whatever).
Not using encapsulation and polymorphism, though, that saddens me considerably. These guys could be having an easier time of it. I hope that they've been learning TDD and refactoring skills, design patterns, etc. Otherwise, they really are struggling more than need be.
BTW: A lot of people think that M$ Windows is the most prevalent operating system. That's not even close to being true. MS doesn't even have 95% of the desktop space. The single most ubiquitous operating system on earth is ITRON, a Japanese embedded operating system, according to a recent article. After all, there are probably more cell phones in the world than there are desktop computers, and those are not the only kinds of non-desktop computers. I suspect that with more devices coming out all the time (mp3 player, mpeg video, bluetooth, etc) we'll quickly see that the vast majority of programming will be for non-Windows, non-desktop computers.
Indeed, we've reached an age of ubiquitous computing before we've reached an age of software maturity. But that's an opportunity, right?
Not using encapsulation and polymorphism, though, that saddens me considerably. These guys could be having an easier time of it. I hope that they've been learning TDD and refactoring skills, design patterns, etc. Otherwise, they really are struggling more than need be.
BTW: A lot of people think that M$ Windows is the most prevalent operating system. That's not even close to being true. MS doesn't even have 95% of the desktop space. The single most ubiquitous operating system on earth is ITRON, a Japanese embedded operating system, according to a recent article. After all, there are probably more cell phones in the world than there are desktop computers, and those are not the only kinds of non-desktop computers. I suspect that with more devices coming out all the time (mp3 player, mpeg video, bluetooth, etc) we'll quickly see that the vast majority of programming will be for non-Windows, non-desktop computers.
Indeed, we've reached an age of ubiquitous computing before we've reached an age of software maturity. But that's an opportunity, right?
Tim, You missed C, that is the most prevalent embedded programming language. And with more developers responding that they use inheritance than use polymorphism means to me that about 8% of the respondents are misusing inheritance.
Yeah. And c++ compilers can very well be used as a (much) better C if you bother learning a little about inlines and all that. It wouldn't hurt me to see that a lot of people are using C++ as a good C.... if they're using it as a better C and not just as Bad C.
I hadn't done the math for the 8%. But if it were only 8%, that would be awesome! :-)
I hadn't done the math for the 8%. But if it were only 8%, that would be awesome! :-)
That is nice idea and it has been hovering around quite a bit. In fact, the problems that put most strain on C programmers ("You did it well. Now there is JUST this little ADJUSTMENT I want you to make to it") were probably what shaped OO part of C++. OOP didn't need yet another language, but some C programmers (or just Bjarne Stroustrup, at first) needed some OO features badly, but also some non-OO features too. There is a significant part of language that in fact addresses performance issues and inlining is one of them - the evolution from C into C++ probably began with modest steps and satisfying immediate needs of C programmers .
Using C++ as better C is, although a natural step, unfortunately a "middle ground" - not covered with appropriate public knowledge base. No course material will ever recommend using C++ in such a "crippled" way (in fact, if you try to do that in a job interview test problem, you will probably be dismissed) and it is probably a matter of embedded systems' developers guarding their professional pride to blame their ignorance on language limitations. Once they start using C++ as "just a better C" they will be mocked to no end (or at least they fear that) by developers who understand concepts of OO programming. Floodgates will fall and managers will demand new skills from these old dogs. However, it WILL happen eventually, no matter what amount of resistance "old school" puts in. There already is a new generation of embedded systems on a chip that is programmed in Java (originally deemed an embedded devices' language) or Python, other new-gen languages soon to follow... probably C++ will be superseded before it is even given chance in embedded world.
Using C++ as better C is, although a natural step, unfortunately a "middle ground" - not covered with appropriate public knowledge base. No course material will ever recommend using C++ in such a "crippled" way (in fact, if you try to do that in a job interview test problem, you will probably be dismissed) and it is probably a matter of embedded systems' developers guarding their professional pride to blame their ignorance on language limitations. Once they start using C++ as "just a better C" they will be mocked to no end (or at least they fear that) by developers who understand concepts of OO programming. Floodgates will fall and managers will demand new skills from these old dogs. However, it WILL happen eventually, no matter what amount of resistance "old school" puts in. There already is a new generation of embedded systems on a chip that is programmed in Java (originally deemed an embedded devices' language) or Python, other new-gen languages soon to follow... probably C++ will be superseded before it is even given chance in embedded world.
Add Child Page to EmbeddedDevelopersBehindOnTheirLearning