Posts Tagged ‘ethics’

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?

Get Rich Slow

Wednesday, October 23rd, 2002 Michael Barr

By a show of hands, how many of you jumped ship from a stable engineering company to a startup in the late 1990s? I bet if you didn’t, you at least thought about it or had a few offers. I never jumped ship myself, but was straddling two boats at once trying to make a quick extra million on a tight budget of night and weekend hours.

I guess I always knew the air would come out of the bubble at some point. And I sure as heck knew it wouldn’t be good to be on top if that happened. So my partners and I kept our day jobs and focused on long term issues in our business planning. How would we profit from our ideas, in ways other than a quick sale of the company or an IPO? We figured we’d identified a product and a market for it, so needed only develop the code and keep expenses lower than revenues while we tried to increase sales.

Still, though, we crossed our fingers and hoped as much as the next guy that we would time our business just right and make a bundle somehow. We certainly weren’t going to turn down a multi-million dollar purchase offer—and even felt confident enough it was worth that to turn down a bona fide small private funding source and free help from an experienced CEO that would’ve valued the company far less initially.

In the end, unfortunately, the bursting of the dot com bubble took not only the really bad ideas but also many good ones (including ours?) down with it. By the time we had filed our patent application, developed our prototype, and written our business plan, all of the funding sources for search engine enhancements had dried up. I suspect several of the venture capital firms and search engine companies we talked to would’ve jumped at the chance to be involved with our idea just a few months earlier. But the game was up. And two years later—long after we wrote off our personal investments in the company—the venture capital we needed to quit our jobs and work toward profitability still isn’t available. So I have a new plan.

My new plan is to get rich slow. To play the part of the tortoise rather than the hare. Engineering is a good stable profession, and one that generally pays well—especially if you have a specialty as in demand as real-time embedded systems design. It’s really not a bad life, if you can get it.

So rather than try to outwit or outplay, I’ll just try to outlast—and I’ll save every penny I can along the way. Besides, it’s quite a lot easier to stick to your core values and make the world a better place little by little when you’re not busy making an end run. To see how extremely disjoint the two paths can become, witness any of the recent corporate scandals.

Honesty, integrity, and responsibility should be the core values of all practicing engineers. And we should practice them outside of work as well. As fun as both are, there’s more to life than engineering and money. So I’m stopping to smell the roses now more too. It sure is nice to have my nights and weekends back! And that’s worth a lot more than a million dollars to me!

Bad Code

Friday, September 20th, 2002 Michael Barr

Enough with the bad code already! While I’ve been discussing the subject of which language to use for embedded programming and how best to ensure a quality result the past few months, millions of lines of “bad code” have been newly written.

You’ve seen the kind of code I mean: modules and procedures carelessly divided (broken up as if to meet some arbitrary length limit, for example, rather than by purpose); variables randomly named, mostly global, and with a large percentage no longer in use; compiler warnings flagging a myriad of suspicious pointer and type conversions unheeded; comments—what few there are—mostly outdated and in conflict with the nearby code; other comments full of code that once did or meant something to somebody, but now doesn’t (or does it?).

Bad programmers can write bad code in any language. It’s time they and their code were dragged into the light. I’ve encountered bad assembly code, bad C code, and bad C++ code. I’m sure those who program regularly in Ada, Java, and every other language have uncovered bad code in those languages as well.

To achieve the best long-term results, it is often necessary to have the courage to discard such code and rewrite it. If an organization can accept that the existing code was never worth the money spent to develop it in the first place, they can move on and look forward to a brighter future. Ultimately, the costs (including the rewrite) will probably be much lower.

I’ve replaced bad assembly code with new C code that was smaller, more efficient, and easier to maintain. It was also developed more quickly and cheaply than the bad code and had far fewer bugs at integration. I’ve similarly replaced bug-ridden C code with new C++ code that required half the code and data memory—and was just as efficient.

I’m not trying to suggest that C is better than assembly, that C++ is better than C, or even that the original authors in these examples chose the wrong languages to begin with. (I’ve also rewritten bad code in the same language as the original.) I’m just trying to make the point that assembly doesn’t always result in the most compact code; there’s skill involved in achieving that result. And C++ code can be just as compact and efficient as C code—if you know what you’re doing.

That, of course, is the important part: The programmer must know what he is doing. Too often that isn’t the case. However they manage to get themselves hired, bad programmers seem to exist in every organization. The decisions they make and the code they write create more problems, hassles, and bugs than any interviewer can imagine. The costs are unbearable, particularly in real-time/embedded devices.

Well? Don’t just stand there. Do something. If it’s your own code that needs the fixing: read a book like Code Complete and start learning how to write well-structured easy-to-read code, obey the Ten Commandments for C Programmers, and get a copy of lint. The version control system you aren’t using should help you feel comfortable deleting no-longer needed code rather than commenting it out. If the fault lies elsewhere: tell someone who can do something about it before any more serious damage is done.