Posts Tagged ‘ethics’

Breathalizer Source Code to Get a Day in Court

Thursday, February 7th, 2008 Michael Barr

Here’s an interesting news story at the intersection of embedded systems and due process:

http://www.news.com/Police-Blotter-Intoxilyzer-code-must-be-disclosed/2100-1030_3-6227951.html

How many potential bugs might a knowledgable expert witness spot in your code? Are the comments in your source accurate and clean enough for a judge or jury to read?

Building Reliable Systems

Wednesday, September 19th, 2007 Michael Barr

I’m writing this live from the Embedded Systems Conference in Boston, while participating in a birds of a feather discussion moderated by Jack Ganssle. The subject of the session is Building Reliable Systems.

The discussion here amongst perhaps 80 engineers (about 75% electrical engineers by education) initially focused on resources and schedules and the inevitability of bugs, but has now turned to what seems to a more productive thread: specific processes and tools that produce higher reliability.

One gentleman, had a great way of summarizing what needs to be done at a high level:

* Prioritization
* Process
* Metrics

In this view, Prioritization is an input to the Process. That is, prioritization of features relative to one another–as well as the accurate definition of properties such as quality and reliability. These are to be provided by the customer or from engineering management. The Process used for design and development and testing are then guided by these input parameters. Metrics are an output of such a Process, if you strive to generate them. Metrics include the schedule time it took to complete specific feature implementations, as well as bug rates.

On the specific point of process and tools, we’ve discovered that just a few companies represented in the room are using code coverage tools and test-driven development, though most appear to agree these might be helpful in raising reliability.

My bottom line fear: One of the products designed by someone in the room with me right now will kill or maim eventually!

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?

Firmware Code of Ethics

Friday, September 15th, 2006 Michael Barr

WE THE MEMBERS OF THE EMBEDDED SOFTWARE COMMUNITY, in order to protect our customers (and their customers) from the risks inherent in our products, extend product lifetimes, lower long-term maintenance costs, promote the general welfare of society, and advance the integrity and reputation of our profession, do hereby ordain and establish the following code of ethical conduct.

Check return codes. If a function can return an error code, it will almost certainly return one eventually. How will our software recover if it doesn’t even know an error has occurred? We will, therefore, always check all return codes. When an error is detected, we will take whatever action is required to recover safely.

Document reasoning. We make dozens of design and implementation decisions each week; we forget the reasoning behind others at a similar pace. We will, therefore, document all of our reasoning in the code itself. Furthermore, we will update these comments if our reasoning changes.

Use version control. Even when done carefully and with discipline, making backup copies of source directories, commenting out code that might be needed again, and tracking changes in comments is insufficient. The use of a good configuration management tool is a must. Furthermore, we agree to always perform a diff and provide a good description of the explanation for all changes each time a file is checked in.

Enforce coding standards. No matter how proud we may be of our abilities, we do not “own” the code we produce. Our employers and clients own it; we and others are hired to develop and maintain it. The true owners have the right to enforce a coding standard upon our work. If they do not choose to exercise this right, we will self-enforce a standard in line with generally accepted programming practices.

Run lint regularly. Compilers are more concerned with generating code than the correctness of your syntax. Only a static analysis tool like lint can watch over our shoulders to ensure we’re not straying into dangerous or non-portable programming constructs. We will, therefore, include lint in our development process. If we don’t remove all code with warnings, we will at least understand why each and every warning remains.

Perform code inspections. Automated tools are helpful, but nothing is better than a peer review for finding logic errors. Code inspections have been shown to be many times more efficient than any other single debugging tool. We will always review our code as a group at least once before each release.

Assign one tester to every developer. Programmers make lousy testers, especially when it’s their own code they’re testing. For best results, one independent tester should be hired for every developer. And the testing team must maintain and rerun regression tests regularly, to certify that a new release is at least as good as the previous one.

Measure performance. Of course, there are some kinds of tests that are best performed by the engineers themselves. In real-time systems, we shall directly measure interrupt latency and the time it takes each of our critical subroutines to complete. An oscilloscope and a spare I/O pin are quite handy in this regard.

These best practices are easy things to do, and all are inexpensive to implement. A one or two person design team can as easily follow these rules as a 50-person engineering department. If you aren’t following these rules today, there are no excuses for tomorrow.

Going Pro

Thursday, December 11th, 2003 Michael Barr

The recent introduction of the .PRO top-level Internet domain, short for “professional,” and especially the narrow restrictions placed upon its use have got me thinking: Why don’t engineers qualify as professionals? According to the charter of .PRO, only “doctors, lawyers, and accountants” qualify to register such domains. I could not, for example, register the domain MICHAELBARR.PRO and thus market my services as an engineer on the Web.

Why are such folk as doctors, lawyers, and accountants often considered professionals by distinction from other workers? Why aren’t engineers members of that elite group? Like doctors, engineers attempt to debug complex systems and prescribe solutions and workarounds that may or may not work. Like lawyers, we are masters of arcane languages and skilled in making stuff work even in the face of seemingly bad precedents. And like accountants, we sit in our cubicles and crunch numbers—and thus make someone else’s life easier. All four professions are known to pay well and consist predominantly of white collar work.

It cannot simply be that only doctors, lawyers, and accountants are certified to practice in a particular state, as there are professional licensing examinations and boards for engineers in all states too. Engineers who’ve been licensed in this way are generally termed “P.E.’s”, an abbreviation that is short for Professional Engineer. In some states and fields of engineering P.E. licenses are, in fact, requirements for the performance of related engineering work.

I wonder if the crux of the matter isn’t simply that engineering, as a profession, hasn’t been around as long as those other fields. Or perhaps it’s that engineers and the role they play in our society hasn’t, until fairly recently, been as large or important as it is today. In a sense, perhaps the empowering of doctors, lawyers, and accountants with the imprimatur of the state—which developed as the importance of these professions to large numbers of people increased over a long history—is what really made them into elite professionals.

Based on the demonstrated long-term success of the three professional fields, it seems like anything we engineers, as a group, could do to make ourselves more like professionals would be good for individual engineers, the wider group, and society as a whole. For example, during the current downturn there has been much worry that engineering jobs are disappearing overseas. If, however, it was a requirement that any engineer involved in the design of a safety-critical product (or one simply to be approved by the FDA or FAA or another government agency) be certified by the state, such jobs would be tied to this country.

Another upside of the professionalization of engineering might be the wrenching of the power over engineering out of the hands of corporations and management and into the hands of independent engineering firms. Like law firms, such engineering companies would be skilled in specific areas of engineering and licensed to practice in one or more states. They might work on all sorts of different products for all sorts of different companies—essentially based on an hourly billing system that would properly emphasize the quality of the work over meeting a specific deadline.

To accomplish this, of course, more and greater emphasis would need to be placed on continuing education, engineering ethics, and state licensing. Most engineers today get basically no continuing education, which might have something to do with why older engineers as a group are often sidelined or pushed into management. Most engineers today are likewise also not schooled in ethics or licensed in any way; but maybe we should be.

What do you think? Do individual engineers, such as embedded systems designers, have more to gain from state licensing and continuing education than they have to lose? What about society or the greater profession?