Is Embedded System Design a Valued Profession?
Richard Quinnell recently commented in his article Embedded Design Profession Under Siege:
“Embedded systems development as a profession is under siege. Companies like Oracle want to turn the millions of Java web programmers into embedded developers for the Internet of Things. Low-cost development boards such as the Arduino are reducing the need for electronics expertise to the level that anyone with a hint of cleverness can turn an idea into a working prototype.”
The image is a powerful one: the plucky band of ‘old school’ embedded system developers holding out against prolonged attacks from the combined might of several armies. But is there any truth beneath the colourful imagery? And if so, what does it mean both for those under siege and their attackers?
What is Quinnell actually saying?
Being an embedded software designer/developer for more than thirty years, this article rang some bells for me. It’s a topic I’ve thought about many times. If there’s a castle being besieged, I’m probably inside it!
But on closer reading, I think the article is actually saying something much more positive than the alarmist headline might suggest.
Quinnell suggests that more children are learning how to programme computers, as both computers themselves and educational opportunities are more widespread. He’s no doubt referring mainly to the USA; his point about education may be less convincing in the UK where late last year there was a very public initiative to improve teaching of ‘how to code’.
He also points out that we are continually developing better tools for hardware, software and mechanical design of embedded systems. It’s possible to get started by playing around with quite capable hardware and software at very low cost – literally pocket money in some cases. His inference is that this makes senior embedded system designers less useful – or, perhaps, less valued – simply because junior staff can ‘get something working’ much more quickly and easily today than was possible some years ago.
Because of that, Quinnell argues, these dyed-in-the-wool embedded design engineers might be sidelined into specialist niches or used as glorified quality assurance for the creative but incomplete and flakey systems developed by their juniors.
What do we think about it?
One thing that hasn’t changed is that the key to a good embedded design lies in a combination of detailed software and hardware knowledge. The ability to engineer a solution with a good split between hardware and software depends crucially on skill and good judgement that are developed over time, with practical experience of what works in the real world and what doesn’t. This can be supplemented by good tools, but I doubt that the process can be completely automated at the moment.
The availability of good tools, low-cost hardware and the low barrier to getting started must be a good thing if it encourages bright and creative people to get interested in embedded system development. But however inexpensive, effective and powerful the tools are, a developer has to learn the strengths and weaknesses of these tools, and how best to use them to achieve a given goal.
What I think Quinnell misses is that the complexity of embedded systems – and their software in particular – is rising inexorably. At the same time, these systems are quite rightly required to meet ever higher standards of safety, reliability and design integrity. Frankly, even the dyed-in-the-wool stalwarts welcome all the help they can get to make their job easier, whether this be through better tools or continuing education.
Turning “millions of Java web programmers” – or for that matter Win32 programmers – into embedded software developers is never going to be an effective way to develop reliable, safe embedded systems. Without a lot of training, most of those developers are only going to learn the rules of the game by making mistakes, with potentially disastrous results. Reputable companies building embedded systems simply can’t afford to make those mistakes.
Conclusion
Contrary to Richard Quinnell’s apparent we’re optimistic about the future of embedded design as a profession. As better tools become available, the demands on embedded system designers are growing equally as fast, or even faster. outlook, we’re optimistic about the future of embedded design as a profession. As better tools become available, the demands on embedded system designers are growing equally as fast, or even faster.
As a result, there’s still no short-cut to success: a good design still depends on knowledge and hard-won experience actually making embedded systems work in the real world. Of course there’s also a place here for the junior designer, who will learn good practice from their more experienced colleagues in an environment where their mistakes can be caught and corrected before they make it into a released product. Despite the rapid pace of change in tools and technology, this is really no different to the situation (say) ten or twenty years ago.
What do you think? Do you feel under siege, or perhaps part of the besieging army?
