When’s the next quake?

We thrive on change in this industry. The rest of the world both envies and pities us for the rapid pace of change we endure in the embedded systems and electronics industry. Envy because it must be exciting to live and work in such a fast-paced business. And pity because it must be miserable to always be changing job descriptions, employers, priorities, tools, and market dynamics. Remember the Chinese curse “May you live in interesting times.”

But do we really change so quickly? For example, how often in your career have you switched programming languages? Dozens of legitimate programming languages are available but I reckon most programmers are fluent in maybe two and use only one professionally. We may change languages over the course of our careers–graduating from BASIC to C, for example–but such changes are rare and border on religious conversions. Hardware designers likewise may change design methods just a few times over the course of decades. So where's this rapid change we hear about?

C is a very old language by the standards of our industry; surely someone has come up with something better. (Cue impassioned letter-writing.) VHDL and Verilog are equally long in the tooth, yet they underpin our entire business. Plenty of us still write code in assembly language, draw detailed circuit schematics, and debug with a voltmeter.

There's no shortage of innovation from the tool vendors. We can't blame them. Compiler and EDA companies, large and small, continually invent new ways for us to be more productive. Original programming languages seem to sprout up with each new crop of computer science graduates who think they've discovered a better way.

But incremental change sells better than wholesale revolution. Our existing software and hardware tools get incrementally better over time. As users, we're happy to pick up the occasional programming pointer or learn a new compiler switch. We creep up on improvements to our skills and productivity, but we avoid the big changes.

It takes awhile to build up demand for a monumental change. The incremental changes need to accumulate for years before we're ready for the Next Big Thing. Paradigm shifts don't happen overnight, no matter how useful or important they may be. Like geologic plates, the forces need to build up slowly over time until–bam!–there's a sudden release of pressure and the landscape is changed.

It's hard to see where or when that next major upheaval will happen. It's surely simmering in labs and cubicle farms around the world, silently building up pressure. Current methods of creating hardware and software are getting too old and developers are getting too frustrated. But old methods die hard, and as much as we wish for change we're loath to accept it. Maybe after this next project is finished . . .

Jim Turley is the editor in chief of Embedded Systems Design. You can reach him at .

Reader Response


The next quake is now . . . can't you feel it? You are correct when you say “current methods of creating hardware and software are getting too old and developers are getting too frustrated.”

Software development is stagnant; it requires the use of the same old software (C), the same old design methods (state machine), and the same old test strategies (thinking). It’s no wonder that designers are getting frustrated and, dare I say, bored.

There is one other element that you have not considered in this mix and that is what is happening globally. It’s not so much a quake as it is a tsunami that’s headed our way. For example, in the last two to three years I’ve seen cell phone manufacturing and then R&D move from the U.S., Europe, and Japan to China! I sell software to these companies and have observed this huge shift. Barrier to entry into software development is low—the cost of a computer and maybe even GNU build tools. Then add to this the wages that a Chinese engineer gets paid, the single most expensive element in a design and you soon see that there is a compelling reason to move the operation overseas. To make matters worse, manufacturing costs, even if it’s in the 100s or 1,000s, is significantly lower than it is in the U.S.

Software development methods won’t change given that what we have works well and has done so for 30+ years. What has changed is the overwheming supply of engineers capable of good software design with a wage level of 1/10 the U.S. wage rate.

The tsunami is coming and will hit the embedded software (and hardware) development ranks here, just as it did the textile industry several years ago. My advise to survive this coming wave: learn Mandarin.

–Brian Senese
Applications Engineer
San Diego, CA


Interesting article. Some things change but others die hard. Consider that programming has not changed in a fundamental way since Lady Ada Lovelace wrote the first program (table of instructions) for a general purpose computer, one that was built out of gears and rotating shafts! For more than a century and a half, software construction has been based on the algorithm. And we wonder why software is bad! Switch to a non-algorithmic, signal-based, synchronous model and the problem will disappear. True, it’s a revolutionary approach to creating software but, sometimes, a problem can be so hard and costly that only a revolution will do.

I realize that I have made this point in several replies to Embedded.com articles in the past but I think it is an important point to be made. Embedded software, more than any other type of software, is crucial to the world’s economy because it’s in almost everything we manufacture. However, it will never reach its true potential unless we can find a way to guarantee that our programs are defect-free.

–Louis Savain
Software Engineer
Miami, FL


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.