A crisis is looming if we can't squeeze more code from our existing developers.
Our industry is nearing a crisis. Much like some of the other crises we face (can you say “global warming”?), this one is definitely coming and no one seems to be doing much about it.
The crisis I'm referring to is the shortage of programmers worldwide. This issue is staring right in the face of an exploding amount of code that must be generated to keep up with all the coming devices, along with the growing numbers of features within those devices.
Add MP3 capabilities to your mobile handset? Sure, it's just some extra code on top of the horsepower that the processor vendors are happy to provide. Add some smarts to your washing machine? Just add some code to that peppy microcontroller. Have your car recognize your Bluetooth-enabled handset? Same deal.
So, where does this leave us? First, the vendors with the code-generating tools claim they can deal with the problem. Generating the code is the easy part, they argue. The hard part is getting those developers to buy into the fact that they can have their code automatically generated for them.
It sounds like a simple solution, but it goes deeper than you might think. And if you're one of those developers who avoids the latest code-generation tools like the plague, you know exactly what I'm talking about. How can a tool automatically generate code as tight as I can write it by hand, many of you say. That's the way I've always done it, and it's worked pretty well so far, I hear from others.
What first opened my eyes to this problem was a chart that I saw a few months ago that plotted the number of code developers versus the lines of code that will need to be written in the coming years. While the number of developers did show an increase, it was a fairly slight increase. However, the number of lines of code that will need to be developed is increasing at an alarming rate, at least according to this particular market-research company.
Confirming my suspicions was an article in a recent issue of EE Times . It quoted a report coming from Microsoft that claimed the number of students pursuing computer science is on the decline while the pressures to deal with the coming parallel-programming issues become more intense with the push for multicore processors. Microsoft acknowledged that progress is likely to be slower than hoped for because of this problem.
I contend that we shouldn't ask for less code, nor should we look for more developers. The answer might be right under our nosesmake better use of the tools that are available to us.
Agree? Disagree? Let me know your opinion.
Richard Nass is editor in chief of Embedded Systems Design magazine. He can be reached at .
Where are all these jobs?
Is this Windows programmers or is this Embedded programmers?
Is there a serious lack of programmers now?
It seems like the Embedded programmers are a hard group to define.
It is a great article. Can you also share the metrics (“developers” Vs “lines of code needed”), which you talked about (unless it is strictly confidential) for two reasons:
(1) Readers who read your article will be curious to see this chart
(2) It will add credibility to what you are mentioning
I'm really sick and tired of reading about the programmer shortage. Has anyone thought of looking for programmers in the unemployment lines?
“The need for more programmers” is a good article, but it is too short. We must analyze the problem in a bigger scale, but yes this article has succeeded in striking the spark ..!
GE Infra, Energy
Two things will happen:
Programmers will continue to make use of bigger and bigger building blocks. Don't tell me someone is going to write that Bluetooth stack for that car from scratch.
Second, when there is a shortage of programmers, the price for programmers will go up, and more people will be attracted to the field.
Mgr, Software Development
H I Solutions, Inc.
I have been in this business a long time. The same things were said about compilers – they can't possibly create code as good as I can in assmber. For awhile, that was correct. For processors like the Z80 and 8080, it was easy to outperform the compilers. But as processors got more powerful and complex and memory got cheaper, it became foolish not to use them. Coding in assembler could still beat a compiler, but the gains were minisucle compared to the time required. The same thing will happen for code generation tools. Currently code generation tools cannot create code as efficient as a competent programmer. But the power and complexity of multi-processor systems will dictate their use. The efficiency gained by traditional methods will not be worth the time required.
A bigger problem, as I see it, is correctness verification and testing. What are the tool makers doing to ensure the correctness and testability of the mountains of code that will be required in the future?
ATK Missile Systems
I think both global warming and programmer shortages are misleading extrapolations of statistics. To gain support for more technical visas, a “crisis” is always helpful.
The conversation continues . . .
Programmers will adapt, even the recalcitrant embedded ones (like myself). I have been in the industry over 20 years and even I can learn new trick.
I recently had to some extensive refactoring of embedded code in a very short time frame. I sat down with one of our savvy developers and used a modeling/code generation tool. After an hour it provided a great skeletal framework for the new code architecture–something that would have taken a day or more. We successfully finished the refactoring that night.
IMO, this is the beginning: intially using such tools for framework/boilerplate code and as familiarity and trust in the tool comes, so will the code.
The vast majority discuss programming languages or software applications, but a few discuss software itself (Pressman and Herron “Software Shock”, Dorset House, 1991). I appreciate that the discussion about “software itself” is opened again.
I always was wondering what all these programmers are doing–if more managers where thinking about how to do the work instead of thinking who will do the work, much more would be accomplished.
When I started programming thirty years ago I always looked for tools first. Most people don't. They are happy with what they have.
The first improvement in efficiency I made writing my own productivity tools, and the result was working with Forth.
I was so thrilled about the gain in productivity, that I made a presentation at the electronica fair in Munich 1986.
But disillusionment followed immediately: I demonstrated proudly to a C programmer how powerful this programming language is. His reply was: “Real programming is hard work. First you have to write the code, then compile it, and then debug it. You type your words (he said to me), and it works–this is children's play, it is not programming!”
My experience over the time convinced me that most programmers love the challenge, the hard work. And they like their accustomed environment. Making a programmers life easier seems not to be welcome.
There are improvements meanwhile, of course. But most of them do not look much different to the kind of programming I learned in my first lesson. “Good contracts make good programs” surely is an important approach. It just had his 20th jubilee last year–takes a long time to recognize good things (see Leibson's Law)!
The problem with programming languages is that most of them are developed by companies to sell their products or by university professors to teach their students. We have C, successor of B, child of Bell Labs, recently we got D, “a new language born out of practical experience implementing compilers” (Michael, Digital Mars), we got E (Mark Miller), but it seems there is a long way to F (Chuck Moore), a real different, but exceptional productive programming language and tool.
My personal opinion is that we are on the verge of real graphic programming. Symbian programming language surely is the step into the right direction. But the real breakthrough will be a combination of all improvements we learned all over the years, combined into a new powerful and easy to use graphical programming tool language.
The future will show a demand on easy programmability for a lot of devices–the big “smart house” and home entertainment markets.
Embedded Systems Engineer
I'll believe that companies are interested in the productivity of programmers as soon as my ratty cubicle is replaced with an office with walls and a door. Until then, it's just talking in the air.
I think if we get rid of the bottom 10% of programmers (the ones with negative productivity), productivity will soar.
Raising salaries will only attract more people to the industry who are ill-suited to it.
Massive code reuse! Hey, that is the answer … massive code reuse with the bugs included too, eh? Even though my answer is mixed with a heaping dose of sarcasm … we have seen how effective this is with Microsoft Windows! I have seen, with my own eyes, this 'good-enough' metric being re-applied ad infinitum.
Sr. Embedded Systems Consultant
Aurium Technologies Inc
San Jose, CA
The conversation continues . . .
I have also been in this business a long time. Throughout that time, I have heard about development tools being subpar along with a shortage of programmers (remember hearing that in the late '90s?). Tools have improved (model-based development, autocoding) and offshoring has occurred. It's not that programmers are in short supply; it's the qualified software engineers who can utilize the given tools to design the bluetooth automotive subsystem to link with your handset who are in short supply. If you pay them enough, supply and demand will kick in, and they will be available.
Real-time Embedded Software Engineer
I agree with Mike from GA, sometimes politics get in the way of true laissez-faire capitalism. The “crisis” of the missing programmers will of course lead to more visas to keep the wages artificially low.
I've been a programmer for over 25 years and the problem is the method that businesses use to find programmers and the rapid growth of technology. Instead of trying to find a logical thinking person who is capable of learning the technology that they are using, companies are always looking for people with a few years experience with the technology. So an excellent basic or C programmer can not get a job working in Java, etc., etc., etc.
Also there is the problem of companies staying with technology long after it has become obsolete and their programmers don't have the opportunity to work with new technologies. Then once a programmer learns a new technology he doesn't want to get stuck working with the old stuff. Anybody, aware of this program will soon realize that being a programmer is a bad job. If you have the intelligence to be a programmer it's better to go into a more stable field that isn't being outsourced.
I still love the field and look forward to learning Vista and .Net 3.0 but I realize that it's like being in the special forces of a never ending war. I don't recommend to anyone else unless they know in their bones that this what they want to be.
If companies would just start hiring people that have programmed and give them a month or more to get up to speed, they will have more then enough talented people to do the job.
Programming is like learning to play a very complicated instrument. A musician who understands the concepts of music will be able to play it and play it well given enough time.
owner of Rouse Software Construction LLC
I take issue with your editorial that our industry needs more programmers. We already have too many programmers. What we need is more designers or, better yet, more software engineers. Programming is no more important to software engineering than drafting is to mechanical engineering or layout is to electrical engineering. Programming is the means by which we realize our designs. Without a good design programming is irrelevant. A wise person once said, “Garbage in, garbage out”.
The magazine took a great stride forward when it changed its name from Embedded Systems Programming to Embedded Systems Design . It will arrive when the name is changed to Embedded Systems Engineering .
-James M. Berry
I agree with your recent #include: “the need for more embedded programmers” and also have seen the statistics related to increasing lines of code due to code complexity per developer project, as well as on the decreasing number of knowledgeable embedded programmers. I wish to share my thoughts on why code-generation methods are not moving faster toward adoption.
I think it boils down to the simple fact that we are creatures of habit. Case in point — the traffic here in Austin, Texas is very congested due to growth. Each day I drive the same 50 min., 19-mile journey to the National Instruments' campus. One morning, due to a traffic accident, I took an alternative route and found that it could lead to a somewhat shorter daily commute. The reality is, like most people, I go on autopilot and often start down the same old road without thinking about a new shorter path.
Code-generation technologies have been around for a long time. Software evolution must transition to a new S-Curve because hardware performance has equalled Moore's Law, but software has not. Will software engineering change? What more likely will happen is that a new technology will enable creation of a new form of software engineer. This new definition of embedded engineer will embrace new ways to overcome the growing lines of code needed for complex, embedded applications, while software engineers locked into traditional programming methods will decrease over time.
As an engineer at NI for over 19 years, it's similar to when we introducedgraphical dataflow programming to test engineers 20 years ago. At that time the majority were Fortran and assembly developers. After many years growing adoption within the academic community, while at the same time targeting new industry users, graphical programming for test became a known and an accepted de-facto standard. One can also make the same comparison with the change from embedded assembly to C. Embedded programming in C generated a new set of coders.
I think the near-term rescue for embedded is a hybrid approach. At NI, we are now to a point where LabVIEW is starting to be used to create LabVIEW. Some of the 1,500 person-years dedicated to LabVIEW core is changing from C code to LabVIEW architected code. The question remains to be seen if in the future all LabVIEW core will be created with LabVIEW itself? Jeff Kodosky, the father of LabVIEW and still active software technologist, says all code grows stale over time and needs rewritten. Is that an opportunity to re-write this code in LabVIEW?
So, do we work hard to convince existing coders to change, or do we target the new set of embedded software engineers that the Code-Generation adoption S-Curve will create? We probably need to do both. We need to show coders the merits of a hybrid approach, while at the same time tailoring tomorrow's embedded software tool feature sets to the characteristics of a “new” breed of embedded engineer. This change is happening today in the university space. On Friday, May 11, I was honored to take part in the ribbon cutting ceremony for the “National Instruments Embedded Systems Design Laboratory” at Berkeley University's Electrical Engineering/Computer Engineering Department.
Some of the existing embedded engineers will change and some will not. What is exciting about the future is that we both will have a new group of enthusiasts to share knowledge and experiences. Examples of those enthusiasts are eight-year-old children who program multi-threaded, near real-time embedded systems using Lego NTX.
Embedded Design Business Unit
I couldn't agree more with William Weber. We have been using Rational Rose for a long time here and it has proven to be a good strategy for both coding and documentation.
Furthermore as these tools are now.
Nokia Siemens Networks
What is the point of complaining about a programmer shortage when programmers are being asked to do Software QA? There are lots of software QA jobs being posted which require the applican to be a developer!
Hire people to QA the software during all the phases of software development lifecycle, and viola! The so-called “programmer shortage” is gone.
Not that there was a programmer shortage in the first place, mind you. Just check out the message boards out there that programmers hang out on. They're complaining about the huge unemployment rate among this industry.