Posts Tagged ‘engineering’

Programming as Profession

Wednesday, January 14th, 2009 Michael Barr

Doing my daily reading around the embedded systems press, I happened across this gem in an article by Jim Turley:

Programming is often treated as a creative endeavor, undertaken by spirited and talented artistes who cannot or should not be shackled to convention, regulations, or reasonable hygiene. Get over it. Programming is a job like any other, and an employer’s responsibility is to ship a profitable product, not coddle and babysit self-indulgent hackers.

I couldn’t agree with Jim more. It is especially unfortunate when a lack of professionalism shows itself in the realm of embedded systems, such as medical devices, that put human lives at risk. I regret to inform the reader that from Netrino‘s vantage point as consultants we see everyday the train wreck that results from poorly managed and unprofessional programmers working in the embedded systems space.

You need a license from the state to to be a barber. To write embedded software, you simply need to be able to spell ‘C’. But I’m on a mission to change that.

Educating Embedded Engineers

Thursday, March 20th, 2008 Michael Barr

One of the biggest problems affecting the embedded systems industry is a shortage of properly skilled firmware developers. I spoke of this in a recent video interview.

Embedded software developers need some skills taught to Electrical Engineers and others taught to Computer Scientists. They also need practical hands-on experience. Unfortunately, even the best of the Computer Engineering programs at Universities fail to deliver the right mix for embedded work.

The demand for such skilled help is growing rapidly–with the latest estimates put at over 4 billion embedded products manufactured per year.

Fellow Embedded Guru Mike Anderson wrote a nice piece about all this for an IEEE-USA publication called “Today’s Engineer.” I happened across Mike’s article in print, but you can find it online by the title “Help Wanted: Embedded Engineers.”

I Are an Engineer

Friday, June 8th, 2007 Michael Barr

Here’s a mocked up fun t-shirt I wish I owned…


EngineerTee.tiff

Educating Engineers

Friday, September 22nd, 2006 Michael Barr

Engineering is a fast-moving field. Even embedded systems design, which is known to use decades old tools, sees new processors and new peripherals and higher speeds and new languages and new techniques arrive continuously.

Unlike the medical profession, which requires continuing education to keep pace with changes in the knowledge base, engineers generally stop learning formally once they obtain a University degree. There is no such thing as Continuing Engineering Education credits.

Symptoms of the resulting intellectual stasis include not only a failure to keep up with evolving best practices, but also the perpetual desire of businesses to hire younger, freshly-educated engineers whether here or abroad.

If we as engineers are to continue to deliver value commensurate with our growing salaries, we must dedicate ourselves to the kind of perpetual learning required in other professions. Only then will the trend toward the use of more fresh-out and offshore engineers be slowed.

What do you think?

The Limits of Knowledge

Friday, November 7th, 2003 Michael Barr

The practice of engineering has often been likened to a form of art. It is, I think, the art of making scientific tradeoffs. As scientists with a practical, rather than academic or theoretical, focus, we are often challenged to build things on the basis of information at or very near the boundaries of what is known to man.

In virtually all endeavors of engineers, there are unknowns, subtleties, and complexities over which we exercise limited control. The cost, in engineering time and resources, to fully comprehend everything about a system is in some cases unbounded; such a thorough analysis is generally at least cost prohibitive. If the product works, we can’t often afford to do much more than ship it and move on to the next project.

Just as tradeoffs are made in the area of features or implementation techniques, so too must tradeoffs be made in the area of knowledge. It is rarely possible to build a saleable product (that will also earn our employer profits) while at the same time completely understanding all of the possible implications of our numerous design and implementation decisions.

Simply put: components fail. And when individual components fail they can take even carefully-designed systems down with them. Such system failures do sometimes also take the lives of their operators or other people. Catastrophes like this are unfortunate—and bound to increase as people rely increasingly on technological solutions to everyday problems.

The designers of each system must decide how much time and money to spend investigating the dark corners. Those designing pacemakers and airplanes, for example, are responsible to shine the light of knowledge brightly in all corners of their designs; whereas the designers of stereos and televisions can leave a great deal more to chance.

There are, of course, areas of engineering that suffer from the need for thorough analysis but are not profit driven. Manned missions to space, such as those conducted by NASA, are of this nature. Tremendous efforts are made by the engineers working at NASA to understand all of the complexities and potential failure points of the Space Shuttles. Unfortunately, there is likely an unbounded amount of work to be done; these systems have millions of individual components and operate in unforgiving and poorly understood environments. And there’s only limited time to show results.

As the losses of the Challenger and Columbia have demonstrated, sometimes it is a part of a design that is thought to be reasonably well understood that is actually the most dangerous. In both cases, very similar past failures had been observed, documented, and discussed by engineers—yet the true problem and the danger it posed was not fully comprehended until after each catastrophe struck.

I don’t blame the engineers at NASA for the loss of either shuttle; in both cases they knew there was a problem but had too many other, seemingly more important, concerns. I’m willing to let NASA administrators and their overseers decide if managerial mistakes were made and, if so, how to correct them. But all engineers everywhere should learn from NASA’s mission failures: What is the true source of the problem in your system? What danger does it pose? How can you overcome organizational challenges to see the proper solution through?