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.
“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.