All engineers think they know the truth about embedded product development. It's hard. It's time-consuming. It's expensive.
But that's only part of it. Unfortunately, the hard truth about embedded development needs to absorbed, not intellectually, but viscerally, through late-night work sessions, missed deadlines, and lost sleep. And the hard truth is this: Embedded development is big and slippery, easy to underestimate, and costly enough to break the budgets of the uninitiated.
Experienced embedded developers and consultants know this. They've seen teams work for years on embedded projects that were supposed to take months. They've seen development costs balloon by factors of 10 or more. They've seen whole departments give up on embedded projects that grew to encompass 40 or more engineers and software developers.
Wind River's Platform for Android served in an in-vehicle entertainment system built by Clarion. (Source: Wind River)
"I saw one company that was five years late and $40 million into their design, using a home-brewed operating system and an elaborate new programming language, and I had to recommend that they cancel the project," Jack Ganssle, an embedded consultant and founder of the Ganssle Group, told us. "And when I made that recommendation, the engineers were almost giddy. Their frustration level was so high that they were hoping to hear something like that." Ultimately, the company took Ganssle's advice and threw out the project.
War stories like this one are common, largely because embedded development is filled with pitfalls that confound even the best engineers. And that's especially true for mechanical engineers, who are coming late to the embedded world and often don't have a scrap of programming experience to fall back on.
Great point about agile development practices, William. I'm hearing more and more about those as I start to dive into cloud-based design tools and mobile apps. It's definitely a mind set change. Hopefully, it's a practice being woven into new curriculum to help engineers get their arms around how to do it adeptly.
Beth: As a former hardware guy, I feel comfortable saying this: Those of us who were educated in mechanical/electrical in the 1980s or earlier are have more trouble bridging that cultural barrier that you refer to. We've been trained to think in terms of hardware, and it's a tough habit to break. Maybe it's a bit of an ego thing, but it's tough to say, "Yes, software is the most important part of our product."
Very good point, Bill. The smartphone industry HAD to learn agile software development to survive, given their rate of progression of their products. Others need to learn to follow their lead.
Charles, really good article and lots of good points!!
I know and have been on those projects that seem to keep going and going and begging for someone to put them down. Many good projects have over run budgets or just failed due to poorly written or no requirements or requirement creeping or engineer's free give aways.
If I had a .01 for every time I've heard an engineer say I can do this better and it would be nice to have this extra feature and just write it in without really understanding it is out of scope and most likely budget, I would be a millionaire.
I remember having to fight management to purchase good lab equipment to test our designs. It cost the company more money and the designers unnecessary time due to fighting with management to get what we needed to get the job done.
Great article, Chuck. You have hit many of the major pinch points in embedded development.
I like your first point "It's all about the software" and your second - "Software is a relatively new field... and we're really still figuring it out". The difficulty arises from Moore's law -- with every 18-months the capability of each component doubles as we continue to innovate.
Five years late with their product? That's more than three generations out of date before the team launched their first product.
If the development team decided to use traditional "requirements-based" project management, they need to freeze the requirements and build to the original specification. But as most teams find out quickly, even if they don't change requirements for new technology, the requirements change because of unanticipated difficulties and incorrect assumptions made by the original designers.
May I suggest an initial "Zeroth Point" on your list: "0. Use an Agile Software Development Method". Once the team develops using Agile methods, the subsequent components on your list are still important, but can be altered with less difficulty. The smart-phone industry is one of the best examples of successful Agile development. Pushing software updates to the devices, new models with new features arriving often, and using standard ports and interfaces so upgraded devices can be swapped out with relative ease are slowly becoming the norm.
"Software is a relatively new field -- only about 50 or 60 years old -- and we're really still figuring it out,"
I think this is one of the best points in the article. This is a relatively unrecognized fact in the computer world. There is a lot about software that we are still trying to figure out.
Great job, Chuck, highlighting the common misperceptions and challenges associated with embedded development. The whole notion that the development effort is predicated more around software design, not hardware design, is a huge cultural barrier for many engineering organizations which may lack a deep pool of expertise in that area and for years, have priortized and emphasized non-software related development.
The tools are also a huge issue. You talk about the need to invest in development tools specifically around writing embedded code. There also needs to be an investment in tools that integrate the embedded development effort with the rest of the product design effort, both mechanical and electrical components. If all the work is done in silos, you can run into intercompatibility problems and design snafus late in the cycle when it is expensive to make changes.
A new book by Thomas Edison's great-grandniece takes on the notion that he was a lone-wolf inventor and replaces it with an image of a man who ascribed great value to the ideas of colleagues.
In response to rising interest in autonomous vehicles, the federal government has called upon states not to authorize operation of self-driving cars, except for the purpose of testing.
With LEDs dropping in price virtually every year, automakers have begun employing them, not only on luxury vehicles, but on entry-level models, as well.
Using almost 200 light-emitting diodes in the front and back of the new 2014 CTS, Cadillac designers are showing how LEDs can change the character of a vehicle.
From Dell / Intel® New Paradigms in Design Work Scott Hamilton, vertical market strategist for Dell Precision workstations, 5/2/2013 5
Early in my career, I worked as a draftsman and remember the days of drawing on vellum with numbered pencils and Mylar with plastic lead. This was a fun experience in the sense that I ...
I've been using workstations for more than 10 years and love finding ways to get more performance from my system. With demanding professional applications that require more power each ...
A lasting memory from my first job as an engineer in an auto assembly plant is standing on hard concrete at six in the morning, vending-machine coffee clutched in hand, listening to ...
For industrial control applications, or even a simple assembly line, that machine can go almost 24/7 without a break. But what happens when the task is a little more complex? That’s where the “smart” machine would come in. The smart machine is one that has some simple (or complex in some cases) processing capability to be able to adapt to changing conditions. Such machines are suited for a host of applications, including automotive, aerospace, defense, medical, computers and electronics, telecommunications, consumer goods, and so on. This radio show will show what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.
To save this item to your list of favorite Design News content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
23 
