As anyone responsible for the development of new products knows, software engineers come in two distinct flavors; engineers that work at the application level and engineers comfortable working at the hardware level. 

 

While this is, obviously, a gross oversimplification, the basic division is true. The application software engineers work in a space that has dramatically expanded over the past several decades; workstation, then PC, then mobile applications; database, followed by data analytics and AI, server applications, then cloud. You get the idea.

 

However, embedded engineers still work within the constraints of real-time control across the entire spectrum of devices and capital equipment. The number of software-driven devices continues to expand at a rapid rate, the supply of embedded software engineers, however, doesn’t seem to be anywhere near keeping up.

 

Traditionally, Made up of Engineers with “Hard Science” Degrees

 

The ranks of the embedded software engineers were initially almost exclusively filled with electrical and mechanical engineers that had strong software skills to go along with the deep understanding of the hardware that was being controlled. In the early 1990’s most academic engineering programs expanded to include “Computer Science/Computer Engineering”, to provide industry with “Software Engineers” having deeper understanding of mathematics and engineering disciplines. This provided a different skill set from the traditional non-engineering Computer Science degrees that primarily focused on data sciences and the operation of large-scale computer systems. 

 

By the early 2000’s, thousands of these “Software Engineers” with the new engineering Computer Science (CS) degrees were being graduated from US colleges, but the ranks of embedded software engineers were still predominantly made up of ‘hard science’ EEs. In 2009, US schools were still graduating almost twice as many EEs as CS students (9,800 to 5,650). 

 

But, in the 2010’s this trend changed rapidly. By 2014, the graduation rates were almost the same (11,300 to 9,300) and by 2018 new CS degrees outnumbered the EEs by 50% (13,700 to 19,100). This shift in academic focus will only continue in the future.

 

Young Computer Science Graduates Prefer Working in “Pure Software”

 

While both majors showed solid growth during this period, graduating EEs increased by 50%, while CS degrees increased by nearly 300%. To exacerbate the hiring situation for device and equipment OEMs even more, the majority of these new CS graduates preferred to work within “pure software” application spaces, such as mobile, cloud, AI and advanced analytics. This pattern is most evident when looking at the average age of the two classes of engineers; in 2021 software engineers had an average age of 31, while embedded software engineers average age was close to 44.

 

While this is a boon for the development of the more sophisticated data “backends” to modern devices, it has made attracting (and retaining) the talented engineers needed to develop next generation device and equipment much more difficult – never mind building competent groups to manage and maintain the tens of thousands of different products already in the field. The question is, if the availability of embedded engineers is already short, and the trend is for the shortage to accelerate, what should OEMs dependent on this skill set do?

 

Evolution of Embedded Tool Sets Helps, but Doesn’t Solve the Shortage

 

Software tool developers have been working for twenty years to improve the usability of their embedded software tools.  This has allowed more application software engineers to become proficient in the increasingly complex embedded environments, and to a large degree they have been successful. But a proficient application engineer still has limited skills in deeply embedded environments such as board support packages, device drivers, hard-real-time systems. Even worse, if a difficult real-time bug is encountered such as race conditions, priority inversion or intermittent failures, working at the application level is almost never going to provide sufficient insight to resolve the issue.

 

The underlying trend in embedded software engineering has been in place for over 20 years but is only now manifesting itself with a more acute shortage of skilled engineers available to hire. The situation will continue to become increasingly difficult as the current cadre of engineers moves through their careers and fewer young engineers step in to replace them.

 

Assess your Product to Determine Options

 

Adjusting your product development and maintenance processes to increase the productivity of your engineering staff is one of the most cost-effective steps to address the shortage. Most managers of software organizations know that both sustaining engineering and new product development efforts are prone to sometimes extreme schedule overruns. Taken from a different perspective, these overruns provide insight into potential productivity improvements available for the engineering organization.

 

There are formalized approaches available to objectively assess root causes for these productivity losses that are responsible for increased development and support costs:

 

• Poor / Outdated Development Tools or Environment – As mentioned above, development tools have evolved enormously over the past decade. Using poor or outdated software and debugger tools or testing strategies will have a direct negative impact on the productivity of your development team. Integrated development environments (IDEs) (including personalized IDEs), multiple screens, advanced debuggers, high-fidelity emulators all can contribute to productivity gains in the hundreds of percent, however, all require investment in training of the staff to fully leverage the capabilities.
• Poor / Inconsistent Product Development Processes (PDPs) – Poor software development processes are easily one of the biggest time wasters in any engineering group in any industry. An evaluation and improvement of your PDPs can directly improve both the quality of the fielded product and directly reduce the amount of effort (and cost) involved. Agile development can clearly accelerate some types of development (but not necessarily all). However, in no case is it an excuse to not clearly capture requirements, architecture and design. Enormous amounts of time are lost in the ‘integration’ process, which is all too often spent implementing missed features or reimplementing parts of the system that were not thoroughly thought through.
• Excess ‘Technical Debt’ is caused by architectural or design ‘short cuts’ made earlier in the product’s life cycle.  It is widely acknowledged that development efforts, on occasion, require corners to be “rounded” in order to get to market on time. However, rarely do organizations assess the ongoing impact of these architectural or design trade-offs to more fully understand the impacts on product stability, maintainability and extensibility of a fielded product. A product architectural assessment can reveal surprising information about how the product maintenance team may be hamstrung by these limitations, causing enormous loss of time and negative impacts to product quality.
• Design Life limits of the Current Product – all products eventually hit a design life limit. Sometimes it’s obvious – components are obsoleted by the supply chain, for example. Other times, it is much less obvious. A product assessment can help determine if your engineering organization has inherited the Sisyphean task of pushing the boulder up a hill, only to have it proverbially roll back down, upending product release schedules in its path.

 

In the case of design limits, it does not mean that a new, design from scratch development effort is required – or even prudent. A product migration analysis can be very effective at determining a strategy to clean up and reuse significant amounts of your key software algorithms – thereby saving large amounts of engineering effort, schedule time, and cost.

 

Embedded Software Engineers will Continue to Become more Difficult to Find, Plan Now

 

The numbers and trends are clear; the shortage of embedded software engineers will continue for the foreseeable future. Accepting this reality and planning now to get more efficient, can put your engineering organization in position to improve your market competitiveness by accelerating your product introduction. 

 

A deeper assessment of your product and development strategy can change the game. Full Spectrum regularly helps clients achieve better results by working with their internal teams on product assessment and development strategy initiatives that lead to improved quality and lower costs.

 

Or, you can spend more money on engineering recruiters to chase ever scarcer resources.