Embedded programmer shortage: A problem, but what kind? How bad? And how to solve it? - Embedded.com

Embedded programmer shortage: A problem, but what kind? How bad? And how to solve it?

There is an embedded software crisis. But still debatable is the natureand causes of the problem.

Is it due to not enough students going into engineering and computerscience? Or is it simply a matter of too many projects of increasingcomplexity outpacing the number of software developers? Whatever thecause, new high level hardware and software design tools will play animportant role in coming up with a solution.

That summarizes the broad consensus among presenters and attendeesat last week's TechOnline Webinar on “Solving the Embedded Code Crisis,”sponsored by Embedded Systems Design, Embedded.com and NationalInstruments.

Moderated by Editor in Chief Richard Nass, presenters at the Webinarwere Jack Ganssle, president of TheGanssle Group and Technical Editor on Embedded Systems Design; JoelSummer, senior product strategist at National Instruments; Dan Saks,Contributing Editor, Embedded Systems Design (“Programming Pointers”); andMichael Barr, a former Editor-in-Chief of Embedded Systems Design andnow president of Netrino, LLC.

Convinced that the problem is due to fewer college students cominginto technical field is Ganssle pointed to “stark numbers,” that haveconvinced him of the urgency of the problem.

“According to recent IEEE studies, the lines of code increasing 46percent per year while number of programmers and engineers is onlygrowing by 7.5 percent per year,” said Ganssle. “That indicates to methat while there may not be a serious shortage now, there will be. Ithink it is more serious than the numbers indicate.

Illustrative of this, he said, is another IEEE study indicating thatthe number of EEs active in their profession in the U.S, dropped by 8percent between 2003 and 2005. What is worse, according to Ganssle, isa survey by the Association of Computing Machinery indicating thatincoming students who come in with the intent of getting a CS or EEdegree dropped by 60 percent between 2000 and 2004. And of those whoremained, he said, 30 to 50 percent switched majors to some otherdiscipline before graduating. .

“There is a negative bubble forming and growing and it represents aserious problem,” he said, “if not now, at least in the near future. Itmust be dealt with quickly.”

Michael Barr is not sure the situation is all that dire, pointingout that if a snapshot is taken of the engineering employment at anytime during the history of the computer industry, there is always ashortage of software developers, due to the lag time between newhardware and software to run on them. The hardware is always one stepahead, more complex, requiring greater amounts of code and moresoftware developers to write it, he said.

According to Dan Saks, more and better tools are a part of theanswer. Despite that, he said, a lot of engineers and engineeringmanagers stick with traditional methods rather than move to unfamiliar,albeit more productive tools.

While there is a need for tools that help the developers deal withthe problems of ever increasing amount of code to generate, test anddebug, he said, a lot of program managers and even individualdevelopers depend on the 'common knowledge' about a particular tool,methodology or language.

“They place more credence of what they have heard from otherdevelopers about good or bad experience,” said Saks. But rather takethe time to investigate themselves they depend on that word of mouth,using it as a justification for not risking time or money tryingsomething new and untried, he said.

“Very risk averse, engineering and software development managerswould rather not try out the tools and not deal with the problems thatalways occur when something new is being deployed,” he said. It is onlywhen they are faced with a situation that is not amenable totraditional methods that they will look to new tools and methods tohelp them break out of corner they are in.

“Part of the burden for the lack of adoption of new tools andmethods must fall on the vendors providing them,” said Ganssle, “Theyseem to be expecting engineers to accept without evidence that theirparticular approach is what they need.” Much more needs to be done toprove to the developers that their tools do what they say they will do,he believes.

According NI's Sumner, it usually takes some sort of triggeringevent to force a manager or a company to take the risk and make theshift. “That is what happened to aerospace market,” he said, wherecosts, the need for tools that reduced code errors and increased codereliability and safety forced a very fast shift to such tools. “It tooka crisis in that industry to force the change,” said Sumner.

Unlike the aerospace industry, said Ganssle, a lot of engineers,companies and application and market segments just do not feel thatall-or-nothing need to change. “It is not the tools cost that is aproblem,” he said, but rather the costs and the unknowns come into playfor training and education.

Pointing out that broad industry segment shifts such as in aerospaceare the exception rather than the rule, Sumner believes that the futureof more widespread use of high level tools is in the hands ofindividual developers.

“We see continuing resistance at the corporate level, where they arehesitant to make top-down changes,” he said. The change will happenfrom the bottom-up, with the engineer or developer who is on the lineon a project and has the greatest the greatest motivation to try out tonew tools.

“That is our business model. We sell to the engineers, not to thecompanies, because they see the problem and face it every day and aremost willing to consider new alternatives.”


While I certainly agree there is a negative bubble forming in theavailability of code writers due to fewer of these folks graduatingfromcollege, I find the shortfall is made up by those of us long timehardwareguys now pressed into writing embedded firmware.

I've had my hands indesign for nearly 25 years and find the size of the typical design teamisfar smaller than it used to be assuming the same scale of a project.Therefore, I see far fewer pure hardware guys around anymore.

In that spanof time I've seen the 80/20 ratio of hardware design time to firmwaredesign time reversed. So I wonder how many erstwhile bit heads like mehave now switched over to do the bit banging in code.I look forward to more articles from you.

Jeff Blauser


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.