What advice would you give to an embedded newcomer?

Wednesday, October 19th, 2011 by Robert Cravotta

Developing embedded systems is different from developing end applications. For one, when done correctly, no one knows or cares about the embedded system when deciding whether to buy the end device. I remember having to adjust my own expectation and method of describing what I did for a living. Saying I worked on the control system for a part of a larger project, I learned to accept telling the slightly less accurate answer to people about what I worked on – “I work on the Space Shuttle, or the Space Station, or a particular aircraft.” I know I am not alone in this sentiment based on the responses from our first question of the week more than a year and a half ago – “You know you’re an embedded developer when …

In addition to adjusting to a different way of describing my job to others, I learned a number of important concepts about designing embedded systems – many of which apply well to other aspects of life. For example, one lesson I learned the hard way is to avoid the urge to rewrite portions of a system just so it will operate “better”. Instead, make the smallest change possible to get the system to do what it needs to do correctly.

The value of this advice is most apparent when you are working on projects with aggressive schedules. There are usually so many things that absolutely need to be changed and added to a design that routing your effort to redesign and rewrite a portion of the system that is invisible to the end user anyway is a recipe for unhappiness and stress. Not only are you taking precious time away from doing what needs to be done to the system, but you are also producing new sources of errors into the system by touching parts that are not part of the scope of work you are supposed to be working on. The expression “If it ain’t broke, don’t fix it” captures the essence of this advice even if it does not impart why it is usually a good idea to adhere to.

I suspect that each of us knows a handful of good advice we could pass onto embedded newcomers or mentees. What advice would you give to someone learning the ropes of engineering and/or embedded design? Do you have a simple or catchy phrase that captures the essence of your advice? Or do you have an example that illustrates a non-obvious value of the piece of advice?

Tags:

4 Responses to “What advice would you give to an embedded newcomer?”

  1. D. @ LI says:

    Aside from the technical stuff, read the book, authored by Edward Yourdon, titled Death March. Your destiny will include working on many such projects, best to quickly learn how your management is marching.

  2. Jon Titus says:

    Don’t give up easily. You’ll find many sources of helpful information in forums, discussion groups, and on manufacturer’s Web sites.

  3. Eduardo says:

    Choose the right processor for the job. Unless there are tight restrictions involved, it is always better to choose an MCU or MPU that has a little bit more performance than needed, rather than one that you’re not sure if will fit the project. In the same vein, prefer processor that have pin-compatible derivatives and a nice and public roadmap.

    On the software side, don’t assume you’ll never have to use an RTOS nor assume that all projects need one (this last sentence felt a little bit zen).

  4. Paul A. Clayton says:

    Doesn’t “If it ain’t broke, don’t fix it” lead to accumulated cruft, making the system increasingly more fragile and less portable?

    (I understand that engineers face the seduction of perfection or “just a little bit better” which must be reined in by resource constraints, but saying no to every improvement that is not immediately necessary can also lead to frustration and failure.)

    Anecdotal evidence seems to point to there never being enough time to refactor, only enough time to fail at some later date (when adding a new feature or even a new usage pattern mysteriously breaks the system or a change required by the discontinuation of a part takes four times longer than expected).

    (Note: I am just a technophile, having no experience in embedded systems development and having written less than 200 lines of code [probably less than 100].)

Leave a Reply to Paul A. Clayton