Best of Backscatter Vol1

ieee-usa eBooks
presents
The Best of
BACKSCATTER
By Donald Christiansen
from IEEE-USA Todays Engineer Volume 1
Published by IEEE-USA Copyright 2008 by the IEEE. All rights reserved. Printed in the United States of America Edited by Georgia C. Stelluto, IEEE-USA Publishing Manager Cover design and layout by Gregory O. Hill, IEEE-USA Electronic Communications Manager This IEEE-USA publication is made possible through funding provided by a special dues assessment of IEEE members residing in the United States. Copying this material in any form is not permitted without prior written approval from the IEEE.
Table of Contents
Introduction ..............................................................................................................................................................................4 Acknowledgments...................................................................................................................................................................7 About the Author.....................................................................................................................................................................7 ABETS EC2000: Howre We Doin?.....................................................................................................................................8 Reality and the Virtual Engineer...................................................................................................................................... 11 The Engineer: Professional or Business Practitioner?............................................................................................... 14 About Working Together. . . or Not.................................................................................................................................. 17 Engineers as Inventors........................................................................................................................................................ 19 Engineers Cant Write? Sez Who!...................................................................................................................................... 21 Meetings Madness................................................................................................................................................................ 23 Whos in Charge Here?......................................................................................................................................................... 25 Inside Peer Review................................................................................................................................................................ 27 Accidents Waiting to Happen........................................................................................................................................... 30 Designing Junk. ...................................................................................................................................................................... 33 Old Dogs and New Dogs.................................................................................................................................................... 35
The Best of BACKSCATTER Volume 1
Introduction
I suppose Ive written some two or three hundred essays, editorials, and columns over the years. All of them in some way related to our engineering profession. My principal reward is in the feedback from readers often extensions of an argument, sometime disagreements, occasional compliments. Citations are nice, too, and requests for reprint permission. It is disappointing to write something and get no feedback. I always half expected to be approached by a big-time publisher wanting to compile a group of my columns. It never happened. I supposed they were busy working with Andy Rooney or Art Buchwald. I guessed they would have asked about the potential readership of my book. Two or three hundred thousand, I would say. Well, they would respond, Andy Rooney has written eight hundred essays, and he reaches millions, and every week. End of discussion. So I was pleased to get a call from Georgia Stelluto, publishing manager for IEEE-USA, who has overseen the successful publication of many e-books for IEEE-USA. Im planning to put out an e-book of your columns, she said. Im sure it will do well and then well follow it with additional volumes. Great, I replied. Ill help you pick out the columns for volume one. No problem, she said. Ive already done that. Then, I think she followed up with something reassuring like, Dont worry, the readers love all your stuff! I wondered if Georgia was buttering me up for some reason. I need you to write an introduction, she explained. OK, I said. Whats your deadline?I need it the day after tomorrow, she replied. By then, I was beginning to wonder if some author had failed to come through with his or her material, and I was being moved up in the batting order. Be that as it may, I decided a possible step toward immortality is not to be taken lightly. I said OK, and Georgia kindly extended my deadline by a few days. So here goes. To be serious, I am grateful for this chance to encourage further discussion of several issues of perennial importance not only to engineers but to society at large. As I looked over the columns selected for this volume, I was not surprised that most of them raise issues that have no pat solutions. The first is education. Some of the ongoing challenges include how to improve K-12 math/science programs, how to provide an adequate basic engineering education in just four years, and whether the United States is turning out the technically skilled work force needed to maintain its global leadership. I discuss some of these issues in ABETs EC2000: Howre We Doin? Times Are Changing There is a changing pattern in who is attracted to the field of engineering. I see less incentive, and perhaps opportunity, for youngsters to build things on their own. Building things from scratch or from discarded items was once an activity that would steer kids to an engineering career. I consider some modern-day alternatives to this waning practice in Reality and the Virtual Engineer. That essay also touches on the growing requirement for engineers to think and design at a higher level of abstraction than was once the case, and its potential downside.
ieee-usa eBooks
The E-Word I always suspect that engineers do not like to discuss ethics. It might be that the phrase behaving ethically immediately conjures its opposite, namely behaving unethically, and as engineers, we are certain that our profession or its individual practitioners do not behave unethically. Unfortunately, when things we have designed fail, faulty design decisions or unfortunate engineering-driven business decisions are often found to be the root cause. And someone is almost sure to suspect ethical lapses. Since good decision-making is central to the profession, I frequently revisit this topic, as I did in Accidents Wanting to Happen (in which, to avoid frightening readers, I ban the e-word). The saying If it aint broke, dont fix it does not apply to the engineering profession, for, after all, our goal is to produce things that are better than what we already have. Put another way, we are in the business of producing obsolescence. Designing Junk touches on the hazards implicit in this seemingly noble objective. If we are too adept at churning out new products, more and more customers may suspect that if a product works well and is affordable, it must be obsolete, and that engineers may be more intent on creating e-waste than lasting, usable products. You can make believe I didnt say it, but there is an aspect of ethics involved here, too. The Engineer at Work The working environment of an engineer has traditionally been overlooked as a topic of interest in undergraduate education. This is changing a bit under the new accreditation rules, in response to which some universities are emphasizing team projects. Even so, many new graduates may feel as John Pierce did when he arrived at Bell Labs with his Ph.D. from Cal Tech. It was just like wandering into hell, he remembered. He didnt know what was expected of him. So, a number of my columns relate to the process of engineering, and in particular, to the working environment of engineers. In About Working Together . . . or Not, I discuss the intrinsic desire of an engineer to create something as an individual (the lone wolf) vs. the probability that in todays environment of complex systems he or she will have to work as a member of a sometimes very large team. Members of different divisions of a company and of customer and supplier organizations, too, may find themselves part of a development team that seldom, if ever, meets face-to-face. Invention and innovation must take place in such an environment. That team invention is even possible is disputed by one of the most prolific inventors of the twentieth century in Engineers as Inventors. It seems to me that the NIH (Not Invented Here) syndrome, in which an engineer does not want to use, or sometimes even hear about, a technique or development emanating from outside the company (or even from another department) is proliferating. Even if an inventor is aware of how a problem was solved elsewhere, he may not respect the solution. Young engineers are also encouraged to think outside the box, which to some may suggest they disregard, or worse, fail to familiarize themselves with prior work in their own fields of interest. With rare exceptions, engineering faculty do not encourage students to develop an interest in the history of their own technology. This neglect of historical perspective may cause duplication of work, cost overruns, and even reinvention of a broken wheel. This phenomenon prompted me to write Old Dogs and New Dogs.
Recent engineering graduates may find it disconcerting that their work is constrained by budgets, company policies and objectives, and supervisors whose decisions seem to be driven largely by concerns for making a profit. I remember a manager who once advised an engineering colleague of mine who wanted to add a feature that was not in the original specifications of the product he was working on. You can refine this thing forever, but if [our competitor] comes out with one that isnt quite as good before we do, and makes a million dollars, you may be embarrassed, his boss said. Recollections of similar dilemmas prompted my essay The Engineer: Professional or Business Practitioner? As a writer on engineering topics, I would have found it difficult to resist writing about the difficulties of writing about engineering topics. In Engineers Cant Write? Sez Who! I reveal some of my own youthful failures to write so that I might be readily understood by fellow engineers. Through inference, I hint at some ways to improve our written engineering communication. While all engineers must write to document their work or communicate it to others, some engineers are able to complete their careers without ever having to submit a technical paper to a professional journal. Perhaps they are the lucky ones, as they escape the ordeal of peer review. While the real purpose of the process is to protect the reader from erroneous, poorly documented, biased, or poorly presented material, there can be a certain amount of gamesmanship involved. A fellow engineer told me he once labored over a paper he wrote so that it would read as if he were talking to a colleague. It was rejected. But when he recast it in engineeringese, it breezed through the review process. Few readers could then understand it, he recalled. I touch upon some of the pitfalls of the review process in Inside Peer Review. Whenever I ask practicing engineers how much time they spend in meetings the answer is always the same. Too much. I talk a little about this in Meetings Madness, and reminisce about a few of the meetings Ive been part of some good, some bad. The Big Picture Some may think it an exercise in futility, but I like to think about the following challenge to the engineering profession: How can we better control, or at least influence, the way in which the hardware or software that we develop is put to use? Is it really a case of once the genie is out of the bottle we have lost control of our own technology, and in particular its misapplication or misappropriation? If not, who are the players with whom we must work to channel the uses of technology for the betterment of humanity, and, more important, to prevent its detrimental uses? In Whos in Charge Here?, I revisit this open question. Happy reading! Your thoughts and comments on any of the essays/columns are more than welcome.
ieee-usa eBooks
Acknowledgments
I am indebted to Pender McCarter, whose idea it was that I begin writing the Backscatter essays for Todays Engineer in the first place. My thanks also to Greg Hill, who deftly eases them into the online version of Todays Engineer (www.todaysengineer.org), and to Georgia Stelluto for her kind treatment of the columns that she selects and excerpts for publication in Todays Engineer Digest. Also, my thanks to Nancy Hantman for typing, record keeping, and for her general aid in keeping me out of trouble as I research and write each column. D.C.
About the Author

Donald Christiansen is an independent publishing consultant and the former editor and publisher of IEEE Spectrum. He is a Fellow of the IEEE.
ABETS EC2000: Howre We Doin?

When John Pierce arrived at Bell Labs in 1936 as a freshly minted Ph.D. from Cal Tech, he knew little about his new workplace. As he told Andrew Goldstein, an interviewer from the IEEE Center for the History of Electrical Engineering, I wasnt very well oriented. I didnt know much about the real world of science and engineering. . . I sure was in a different world. . . Wandering into Bell Labs [was] just like wandering into hell. But he found his colleagues friendly and helpful in answering his questions, and he did what others suggested. It worked out well. His inauspicious beginning turned into an auspicious career at the Labs, culminating in his position as director of research for the communications sciences division and his recognition as Father of the ECHO Satellite. Today, though, the type of education that Pierce and others of his time received might not be good enough. As far back as the years just after World War II, industry and educators alike began looking for ways to change the electrical engineering curriculum particularly at the undergraduate level so that a new graduate could get into harness (like a Clydesdale rather than a trotter, one supposes) and immediately begin to pull his weight as a productive engineer. The problem was seen to be that while new grads might be technically competent, they knew little about the process of engineering how things were designed, refined, and put into production and what the constraints of real-world engineering might be. Some schools tried nobly to ameliorate this problem. Cornell University, for example, devised the fiveyear baccalaureate in electrical engineering (BEE), in which students would elect courses outside the engineering college to broaden their perspectives, perhaps making them less nerdy, and enabling them to speak and write well. But this well-intentioned program did not last; the opportunity for students to earn an EE degree elsewhere in four years soon drew prospective candidates from the five-year program, and it was discontinued. Most companies kept the dream of hiring the ideal graduate on their perennial wish list, while others assumed the responsibility for providing the necessary indoctrination and training, picking up where engineering schools left off. A widely respected example of this support is the General Electric test program, in which new engineers were exposed to a series of jobs in different departments. But many of the post-World-War-II graduates found themselves in the same situation that John Pierce had encountered a decade earlier in unfamiliar, sink-or-swim environments. Most swam, with the aid of good mentors and helpful colleagues who had been through it all themselves. Later, the solid-state revolution and the concomitant success of electronics companies spawned an era in which continuing education for engineers was encouraged and even sponsored by many of these prosperous companies. It helped that employment for life was then still an expectation. But with the onset of deregulation, mergers, global competition, and downsizing, companies were less likely to support educational programs for their engineers. The drumbeat of discontent with the abilities of new graduates by their employers, never completely
ieee-usa eBooks
stilled, grew once again. Engineering school alumni, many of whom are now company executives, came back to their alma maters as advisory board members, urging faculty to devise new programs that would make their graduates productive more quickly. In response, over the past several years, the Accreditation Board for Engineering and Technology (ABET) devised new Engineering Criteria (EC2000) that have been tested in pilot programs and with which all engineering schools must now comply. Some 100 schools have already been reviewed using the new criteria. The old criteria were heavily resource-based; that is, they measured the quality and quantity of laboratory equipment, computers, number of faculty, and the like. The new criteria are output- or outcome-based. They focus on what graduates ought to be able to do: know where and when to apply appropriate math; conduct and interpret experiments; design things; work on multidisciplinary teams; be ethically responsible; communicate well; be always ready to learn something new; know whats hot in the profession and what the contemporary issues are; and have and use the right skills and tools to get a project done. Professor John Orr, head of the Department of Electrical and Computer Engineering (ECE) at Worcester Polytechnic Institute (WPI) in the Massachusetts area, sees this as a transient period, when both reviewers and schools are coming to an understanding of whats involved. The incredibly difficult part, he said, is defining wanted outcomes so that they can be measured against the mission criteria. Defining outcomes is necessary to improve curricula and educational methodology continually, a requirement of ABET 2000. Despite its growing pains, Orr and others consider the ABET process to be faring well. Design Is Making a Comeback Many schools are placing a renewed emphasis on design. At one time, some engineering graduates would leave school never having designed anything. Not any more. Those who support the design emphasis say that all engineers are fundamentally designers. Research engineers design experiments; design engineers design products and systems; manufacturing engineers design processes and equipment; and at the least they must all be familiar with design aspects of the products and systems that result from the end-to-end process. Many schools elect to satisfy the design requirement through a senior design project. Some schools have led the way with senior or capstone projects, among them WPI, which implemented the project concept in the 1970s. WPI undergraduates today are required to do three projects and usually work in teams. Their junior-year project works with an interdisciplinary real-life problem, often outside the United States. Some schools have introduced elements of design techniques during the freshman year. One might even imagine a complete college program based on a single design project (perhaps an actual design), during which the appropriate educational material is brought in at the point where it is useful for moving the project forward (just-in-time education). Engineering faculty might find the Harvard Business Schools case study approach a valuable role model. If this is all beginning to sound like a graduate program, some faculty would agree. And can resurrected talk of a five-year baccalaureate be far behind? Employers Want Soft Skills, Too Employers are hoping that the new graduates will have better skills in communicating, openness and cooperation, and being sensitive to ethical issues. Faculty are hoping that such non-technical
skills can be integrated into the curriculum or into individual course work without eroding the time available to teach the basic knowledge-based material, which itself is becoming more complex and demanding. One possibility for teaching these new skills may be to incorporate them into the design projects. The challenge to faculty will be to select projects that have believable aspects related to ethics, feasibility, and other real-world considerations, so students will be able to grapple with the tradeoffs and compromise inherent in engineering design. While there is general satisfaction on the direction ABET 2000 is taking, problems remain and differences of opinion related to implementation persist. But the new criteria are intended to permit flexibility on how each school implements its program. Todays Engineer will carry discussions about ABET 2000 in future issues. In the meantime, input from students, faculty, or employers on ABET 2000 or on engineering education in general are welcome. Send your thoughts to todaysengineer@ieee. org. Please include your name, home city and state, and IEEE membership level (if applicable).
10
ieee-usa eBooks
Reality and the Virtual Engineer

Electronic system designers today can cope with a degree of complexity that, before the computer, was beyond our imagination. Sitting before their monitors they can assemble a new system from old subsystems and never touch a soldering iron or walk out to the factory floor. The new, highly complex system will probably work fine, doing things its predecessors never did, but I worry that the designer may not know what is in the old black boxes that are incorporated in the new system. Dont get me wrong. I have great intuitive confidence in the quality of the components in the black boxes. I know that back in some lab physicists and device engineers are worrying about things like stressinduced leakage current and bulk oxide trapping, with an eye toward improving the next generation of whatever is in the black boxes. Yet I have this uneasy feeling that the designers may be losing touch with the hardware. Todays engineer is not as hands-on as were those of an earlier generation. Engineers, of course, are not the only ones affected by our computerized society. There are fewer shade-tree mechanics; who can fix their own cars with all the on-board computers? TV sets and VCRs that dont work are replaced like light bulbs. It is my recollection that young people were once attracted to engineering because of things they had played with or even built when they were in grammar school. I confirmed this by doing a little research: Dave Packard, co-founder with Bill Hewlett of Hewlett-Packard, built a radio receiver at age 12. Hewlett built a pair of crystal sets, one for himself and another for his sister. Both Hewlett and Packard built models and conducted experiments with explosives. The latter were not always successful. Packard would show friends a less-than-perfect thumb on his left hand as proof. A copper tube filled with blasting powder had exploded when he tried to hammer a cap onto one end. This may have persuaded him to pursue electrical rather than chemical engineering! As a teenager, radio communications pioneer Harold Beverage built his first radio and a sparkgap transmitter that had a range of some 50 miles. While in grammar school, Leo Beranek, famous for his work in acoustics and speech communications, strung an antenna between his house and a tree to help bring in stations on a one-tube Crosley receiver. In high school he took an International Correspondence Schools course in radio, built a crystal set, and repaired radios for neighbors. His uncle gave computer pioneer Ross Aiken an electrical kit containing a motor, batteries, and carbon rods (useful in building a microphone) when he was 12. Experimenting with it, he became captivated by electricity. As a youngster, Charles Concordia, known for his developments in power system control, brought his bedspring into play as an experimental radio antenna.
Many other prominent electrical engineers were propelled toward the profession through model building, kit assembly, and taking things apart. Gordon Teal, developer of germanium and silicon semiconductors, said he was always very curious about why things worked and why they didnt.
11
For the mid-century electrical engineers, the hands-on approach continued into college, where undergraduates not only conducted experiments with actual components and test gear, but also were required to do mechanical drawing, make patterns in a woodworking shop, pour castings in a foundry, and turn and grind the finished castings in a machine shop. On their first jobs, new grads were thrust into the real world of hardware. For the circuit designer, this meant the occasional insulation meltdown and smoking components, signals that a breadboard might be about to burst into flame. Notwithstanding the failures, most of these designers recall with nostalgia the aroma of rosin-core solder and the warm glow of vacuum tubes. At home, they built amplifiers, vacuum-tube voltmeters, signal generators, and even TV sets from kits. What is different about todays potential electrical engineers? For one thing, kids toys are mostly ready made, not built from scratch or kits. (Is the Erector set still around? In fairness, Lego offers some of the same challenges.) Entertainment is more likely to consist of watching TV or playing computer games, rather than salvaging wheels from a stroller to build a new wagon. The mouse has replaced the telegraph key, but the technology behind it is beyond the comprehension of most grade schoolers. Kids immersion in this new environment causes me to wonder what the factors are that condition any of them to study electrical engineering. No doubt good teachers in math and science, especially at the high school level, are important. But engineering school faculty say that many who sign up for electrical engineering arrive knowing little about the field, its specialties, its employment opportunities, or course requirements. Perhaps one of the best ways to help young people test their interest in and aptitude for a technical career is through the school science fair. We as individuals might volunteer to help coach participants, even encouraging those who are uncertain about a project to choose one that is electrically or mechanically oriented, as opposed to the many that relate strictly to the biological sciences. Other hands-on activities may be too challenging for grade- or high schoolers. These may instead attract undergraduate electrical and mechanical engineering students. The better projects could be as worthy as some of the design projects being developed by the schools themselves under ABETs EC2000 criteria. Robotry contests, for example, involve many interdisciplinary factors: mechanical design, stability, mobility, motive power, electrical power, software, and the like. Television programs, like The Learning Channels Junkyard Wars, sometimes offer another version of robotry. The show adds an element of risk: a contestants well-crafted entry may be demolished by its opponent! I often think some youngsters, particularly those who excel at and enjoy mathematics, may believe that engineering is exclusively math-centered. I like to remind them that engineering is ultimately product- or service-oriented and that electronics systems are often big, complex, and both hardware- and software-rich. By now you must have realized that the scenario with which I opened this essay was somewhat overdrawn. We all hope and trust that an actual design team would have on it individuals who are versed in all aspects of the system, including specialists in hardware and software reliability. Nevertheless, I offer the following modest suggestion that might help narrow the gap between todays virtual designers and the hands-on engineers of yesteryear. As educators modify undergraduate
12
ieee-usa eBooks
electrical engineering curricula to meet EC2000 criteria, they might do well to consider a mandatory course that would cover electronic components, physics of failure, and elements of systems reliability. Students might also be given the chance to spend a day in a chip fabrication facility. (Yes, a few schools have their own fab labs.) Because the vast majority of todays components are invisible to the naked eye, hidden by the tens of thousands in a miniscule package with lots of pins sticking out, students would benefit, I believe, in seeing their discrete component counterparts a real resistor and a real transistor, for example as well as seeing how integrated circuits are actually fabricated and tested. I think it would lift their spirits, too, bringing a touch of reality to a profession that must take more and more on faith as the things that really do the work disappear into smaller and smaller black boxes. Resources For more about hands-on career starters see: Packard, D., The HP Way, Harper Collins, New York,1995 Wallen, A.I., Genius at Riverhead: A Profile of Harold H. Beverage, North Haven Historical Society, 1998 Brittain, J.B., Alexanderson: Pioneer in American Electrical Engineering, Johns Hopkins, 1992 Farnsworth, E., Distant Vision: Romance and Discovery on an Invisible Frontier, Pemberly Kent, 1989 Also: Oral Histories of Eminent Electrical Engineers recorded by the IEEE History Center www.ieee.org/ organizations/history_center/.
13
The Engineer: Professional or Business Practitioner?

Imagine yourself in this situation: You are part of a project team to get a newly developed electronic device into shape for full-scale production. It is a solid-state device with a significant new function. It could enable any customer who designed it into its line of consumer products to gain a considerable advantage over its competition. A pilot production line has been set up, but to your teams consternation, yields are negligible to non-existent. Your companys marketers had alerted its best customer to the project and provided engineering samples. The customer has redesigned a major product line around the new device, and it hopes to obtain exclusive rights to purchase it for a period of one year. Its marketing people are poised to roll out a major television and print advertising campaign. Your management has elected not to inform the customer about the low yield problem. In just a few days, a high-level group of engineers from the customer is scheduled to visit. Your team knows the visitors expect to view the production line. What would you advise management to do? Cancel or postpone the visit? Tell the customer about the problem? Heres what actually happened. The visit came off as scheduled. After a carefully timed technical presentation in the conference room, the visitors were led to the production area to view the various steps in the production process. Then, to a predetermined timetable, they reached the final test station, where an operator carefully and deliberately put one after another of the devices through their paces. All passed with flying colors. When she completed the test of the sixth device, she excused herself; it was the lunch break. As she made her way to the cafeteria, the visitors were invited to the executive dining room. None were told that the six devices they had witnessed being tested were the only ones available that adequately met all specifications. Each had been pretested, and the operator had waited patiently for the arrival of the visitors, performed the tests, and departed on cue. Duly impressed, the visitors left with full intentions of going forward with their plans. They did so, and the device manufacturer was able to debug the production processes, increase yield, and ultimately put the new device into full-scale production without causing any delay in the customers product introduction. Since I once witnessed an incident very similar to this, I have used it from time to time and with variations as a case history for discussion by young engineers and engineering students. It always provokes comment. For example, why did management keep the yield problem from its customer? Did that action (or inaction) represent an ethical lapse? Should the engineers on the project team have objected to the secrecy, or at least to the test charade? Many employed engineers concluded that the incident was not unusual. They thought it more of a business decision than an engineering decision, although they conceded that the engineers may well have played a role in reassuring management by projecting (or even promising) timely solutions to the yield problem. Some found it humorous, a trivial deception worthy of any competent poker player; a business coup of sorts.
14
ieee-usa eBooks
Students exposed to the case study were more likely to believe that the customer (especially a favored customer) should have been kept fully informed. Engineers who had faced similar dilemmas also favored disclosing the problem to the customer. After all, they reasoned, the suppliers engineers and the customers engineers had in all likelihood worked as partners in earlier phases of the development; why not continue to do so? Managers did not necessarily agree; the suppliers problems were internal and to reveal them could deflate the companys good reputation. This case study is representative of the dilemma faced by the employed engineer. He or she is both a professional and an employee, thus owing allegiance to both the profession and his or her employer. As the engineer assumes managerial responsibilities, the plot thickens. Engineers are by nature and training disposed to honesty and openness, gaining new knowledge and bartering information. They keep corporate lawyers busy defining what information is proprietary, protecting patent positions, and limiting what can be revealed to the outside world. And managers have the daunting task of allowing engineers selective autonomy on technical matters, while encouraging them to broaden their understanding of business factors. Edwin Layton, a professor of mechanical engineering at the University of Minnesota, in his classic book The Revolt of the Engineers, defined the situation succinctly. The engineer is both a scientist and a businessman. Engineering is a scientific profession, yet the test of the engineers work lies not in the laboratory, but in the marketplace. The claims of science and business have pulled the engineer, at times, in opposing directions. The pull that Layton speaks of is seen in many different ways, none so dramatic, perhaps, as that experienced by Morton Thiokols vice president of engineering, who became a pivotal player in the Space Shuttle Challenger disaster. Thiokol was the supplier to NASA of the booster rockets for the Challenger spacecraft. Concerned about recommending a launch in extremely cold weather that could exacerbate a known failure mechanism in the boosters, the vice president called a meeting of his staff. Together they concluded the launch should be postponed. Later in the day, at a meeting of his management peers, he was asked by his boss to think like a manager rather than an engineer. He then changed his mind, voting for the launch. It went off on schedule. An O-ring in the booster failed. Challenger exploded. All aboard were lost. What caused the engineering vice president to change his mind? In the meeting with his engineers, wearing his engineers hat, did he think the consequences of a Shuttle loss would be unacceptable, regardless of any benefits that might be gained if the launch were successful? Then, in the meeting with his boss, donning his managers hat, did he think the risk of a Shuttle loss was outweighed by the potential benefits of a successful on-time launch (accolades to NASA, an increase in its budget, support for future space programs, more business for Thiokol)? In fairness, there were many factors leading to the disaster, not the least of which was the weakness in the O-rings, long known to engineers and managers of both Thiokol and NASA. But the critical factor seemed inarguable to most post-accident analysts the engineering vice president had switched his vote when he thought like a manager. One of the byproducts that scholars see as engineers move into management is a de facto loss of expert knowledge, and a concentration on the exigencies of business. The engineer values knowledge and the manager initiative, loyalty, and team effort, they note.
15
Engineers interviewed as part of a study* of how engineers, engineering managers, and managers work together under normal conditions gave a broad range of comments, varying from We operate by consensus to Technical questions get short-changed to make schedule, and Theyll [managers] sacrifice quality to get it out the door. A manager interviewed in the same study said Engineers have high weight on technical issues. The problem is integrating technical recommendations into company interest. Cost. Marketing strategy. Change in technology. Etcetera. Its important that the engineers recommendations get out beyond [his] immediate group. When he sees how his decision does not fit into the larger picture, hes likely to rethink it. It seems to me necessary and even beneficial, this perennial tug-of-war between perfectionist engineers and their managers, the latter more concerned with price and delivery demands of the marketplace. This contention, or collaboration, as the case may sometimes be, after all represents a check-and-balance system. However, danger signals may be that one party wins too frequently or that the engineers withdraw from the dialogue prematurely. An engineer who fails to make a convincing case for lack of trying cannot expect to shift the blame to his or her boss when something goes awry as a result. Nor should sensitivity of the engineer to the needs of the business require the abrogation of his or her principal responsibilities: quality, safety and the search for technical sophistication and superior design. Resources For more about the engineer-manager interface, see: *Davis, M., Thinking Like an Engineer, Oxford University Press, 1998. Layton, E., The Revolt of the Engineers, Case Western Reserve University Press, 1971; reprinted with a new introduction by the author, The Johns Hopkins University Press, 1986. Pool, R., Beyond Engineering, Oxford University Press, 1997. Vaughn, D., The Challenger Launch Decision, University of Chicago Press, 1996. Vincenti, W. G., What Engineers Know and How They Know It, The Johns Hopkins University Press, 1990.
16
ieee-usa eBooks
About Working Together. . . or Not

I first thought of calling this column The lone wolf: endangered or extinct? That was based on the common belief that engineers who practiced before the middle of the 20th century (up until World War II, say) did their best work as individuals, not in teams. They liked to work alone, and even disliked working with others. And that with the technological watershed stemming from wartime developments and the subsequent complexity of systems, team engineering became the necessity and the norm. Can we possibly imagine todays extraordinary computer and communications systems being developed in any other way? Yet most historians of technology subscribe to the notion that engineers are, or at least were, individualistic and independent, and proud and protective of their own accomplishments. They cite pioneers such as Tesla, Armstrong and Farnsworth, who seemed to do their best work in isolation and did not work especially well in the corporate environment. In those days, it seemed easier to determine who deserved credit for a particular invention. Admittedly, there were contests concerning who was first when engineers working independently developed essentially similar inventions, but ultimately the engineering community, if not always the legal community, was able to determine who did what and when. Contrast that with todays situation. One seasoned engineer, serving as a judge for a major award to an engineer for outstanding technical accomplishment, told me recently that it is more and more difficult to single out one person for the award, or even judge the merit of a nominees contribution. For one thing, he said, the supporting papers are likely to list multiple authors and, likewise, the supporting patents list multiple inventors. It would be embarrassing, he said, to have to ask the nominee, How much of this work is yours? Engineers dont always relish working in teams, despite the need to do so. They embrace the idea of autonomy, and they dont expect the boss or even colleagues to have to tell them how to do their job. They respect originality, and thus neither favor nor enjoy copying the competition. Often they are even skeptical of ideas offered by members of their own project team, particularly if adopting those ideas means scuttling an idea of their own. They may go to great lengths to prove why a colleagues idea is unworkable or at least how their own is better. In part because of todays team approach to engineering, the EC2000 curricula accreditation requires that some undergraduate projects (e.g., research or design projects) be done by student teams. Aside from the technical and procedural knowledge gained thereby, students are exposed to both the advantages and hazards of team dynamics. A student project may fail or be poorly done in spite of technically competent team members. A strong leader may suppress the role of other team members, permitting little or no collaborative effort. The mere presence of a female on an otherwise male team may encourage stereotyping. She may assume the role of data taker or some other non-leadership role, or even become the subject of minor harassment (someone will write me that no harassment is minor, and they may be right). The solution here may be close monitoring of student interaction, or, as happened in one case, tape recording of the sessions for later analysis by the professor and team participants. In any event, these projects provide a preview of what the student may find in his or her
17
first encounter with team engineering in industry. Is there a serious downside to team engineering? Too many meetings? Too much time spent selling your ideas? Too little time for creative engineering? A lack of psychic reward for ones own contributions? When social scientist and management consultant Michael Maccoby interviewed engineers in major U.S. electronics companies in the 1970s, many said they were nagged by thoughts of being merely part of a huge machine. For many, Maccoby concluded, the ideals of individualism persisted within engineers even in the contemporary corporate environment. My senior colleagues and I (old-timers, if you prefer) marvel at the amount and diversity of technical knowledge todays active engineers require and can assimilate, and the amount of time they must spend communicating via e-mail, technical conferences, and face-to-face meetings. How do they find time to think? Junichi Nishizawa, inventor of the semiconductor injection laser, demanded quiet and solitude while working. Prolific inventor Jacob Rabinow said that inspiration came to him in solitary moments while shaving or driving, for example. Could it be that there remains a bit of the lone wolf in each of us that we should nurture? Do we need to set aside some time for engineering meditation? Is there such a thing? Resources For more about the working habits of engineers, see: Ingram, S. and Parker, A., The Influence of Gender on Collaborative Projects in an Engineering Classroom, IEEE Transactions on Professional Communication, March 2002, pp. 7-20. Kidder, T., The Soul of a New Machine, Little, Brown, 1981, Avon, 1982. Maccoby, M., The Innovative Mind at Work, IEEE Spectrum, December 1991, pp. 23-25. Vincenti, W.G., What Engineers Know and How They Know It, The Johns Hopkins University Press, 1990.
18
ieee-usa eBooks
Engineers as Inventors
Someone once said that there is an order of magnitude difference in talent and ability between Michael Jordan and the lowest-paid NBA player, but that the talents of engineers are more tightly bunched. Perhaps. The point could be argued. If patents are chosen as one metric for engineering accomplishment, then we must accept the fact that most engineers have not been issued patents, and of those who have, only a minuscule number reach the Inventors Hall of Fame (the Michael Jordans of invention?). Does this imply that most of us are not inventive? I dont think so. Lawrence Kamm, an inventor and holder of many patents, distinguishes between inventions and patentable inventions. In his book Real-World Engineering, he uses the word invention to mean any good design you think up. That seems to me a reasonable definition. An invention may therefore represent a small yet creative improvement in a product or a process. For a variety of reasons, including the wish to keep an invention proprietary or an employers wish to do so an engineer may not seek a patent. What makes a good engineer, I would suggest, is the proclivity to invent, without necessarily thinking of the process as invention. Is inventiveness inborn or can it be taught? Prolific inventor Jacob Rabinow said, I never had any doubts that one could teach creativity in engineering just as one could teach music composition or any other art. Yet he devised a test that he used to evaluate the inventive talent of prospective engineering employees, and noted that a bright Ph.D. once flunked it. Why Do Inventors Invent? The incentive to invent may vary. Some independent inventors are not concerned about the technical sophistication of an invention or about the field in which they invent. They might tackle a way to open a cardboard milk carton without destroying it, or develop an easy way to find the end on a roll of duct tape. They may invent to solve a problem or to devise something of value to the general public that could also make their fortune. Then theres Jacob Rabinow, who said, I dont invent to make money [but] because I get a kick out of it. Its an achievement, where nothing is at stake. If I dont succeed, the world is not going to come to an end. In the corporate world, problems that arise during a design or development project often trigger the need to invent. But theres little agreement on how one goes about the process of invention. A systems engineer is likely to believe the process can be codified. But successful inventors dont think so; Rabinow says that in seeking a solution to a particular problem, a person figuratively puts all the information he or she knows about the subject on cards and tosses them in the air. They hit the floor in random combinations and the person scans them, looking for combinations that trigger new ideas and discarding those that dont. What is important is the ability to select the good combinations, he said. But the expected price of one good idea, he added, is the consideration of many bad ones. Inventing En Masse? Then theres the question of the lone inventor versus team invention. In recent years several inventors
19
were inducted into the National Inventors Hall of Fame as members of a team. In 2002, for example, four individuals were named for inventing the implantable defibrillator and three for inventing photorefractive surgery. On the other hand, inventor Rabinow insisted that invention by a team is fiction. Inventions are almost always single-minded. And a digital-business consultant, Wally Bock recently wrote it takes individuals with time and a tinge of zealotry to do the kind of work that makes for invention or innovation in organizationsGood creative work pretty much happens in isolation. It can then be modified, massaged, improved upon and implemented by teams, but generally [inventors are] set off by themselves, beavering away and getting the job done. (Is it true that invention cannot be done all that well in teams? I dont know the answer to this one, if indeed an answer is needed. Your comments are welcome.) The Engineer as Inventor In my experience, I have observed that the characteristics that lead to success as an engineer are largely the same as those that define inventive talent. Among them are curiosity, good observational powers, and a tendency to be dissatisfied with the status quo. A questioning attitude is good: How does it work? Why do we do it this way? Isnt there a simpler, more elegant solution? I wonder why it was designed like that? A readiness to experiment also helps: Lets try this. Finally, sensitivity to weaknesses in an existing design helps, as does the ability to anticipate future customer needs. The most important question may hark back to the issue of whether engineering creativity and inventiveness can be taught. How does one know, when hiring a bright young engineer, what his or her creativity quotient is? Can electrical and computer engineering curricula be designed to foster inventiveness? Resources For more about invention and creativity, see: Kamm, L. J., Real-World Engineering, IEEE Press, 1991. Middendorf, W. H., What Every Engineer Should Know about Invention, Marcel Dekker, 1981. Rabinow, J., Inventing for Fun and Profit, San Francisco Press, 1990. Simonton, D. K., Genius, Creativity, and Leadership, Harvard University Press, 1984.
20
ieee-usa eBooks
Engineers Cant Write? Sez Who!

To begin with, it is widely accepted even among ourselves that we engineers dont write very well. In truth, at least in some cases, we write too much; in others, too obscurely. Yet we are stuck with the need to write. We must document and communicate what we do, or what would be the purpose or the result of our inventing, developing and designing? As a young engineer, I was invited to address an IEEE Section meeting. My subject was an unusual stereophonic/ quadraphonic audio system developed at CBS Laboratories. This technical presentation may have been my first before a large engineering audience. I worried at the prospect. I prepared and projected a number of slides containing a bunch of mathematics that no one could follow during their brief exposure. After all, I had sat through many conference papers that were ritually peppered with unintelligible (at least to me) equations. I had responded in kind, despite my audience having many spouses present most of whom hadnt a clue what their mates did for a living. I was grateful to the wives, who did not boo or stamp their feet, but discreetly nodded off. The saving factor was that I concluded with a stirring demonstration of the audio system that elicited many compliments. Nevertheless, after the talk, a colleague asked me why I had included all the theory, especially in view of the mixed audience. I could not give him a good answer. I was an engineer, I thought to myself. The theory and the supporting math seemed obligatory. But I took the criticism to heart. Later, when the paper was published for a strictly technical audience, I heavily edited the math, converting it whenever possible to a word statement of what was physically happening. What is it that drives us to embed our writing in arcane mathematics and phraseology, and to encumber it with acronyms decipherable only in context and by the knowledgeable and sometimes, not even then? Could it be our response to the obscure, Latin-rich writing of the medical profession? Are we hoping somehow to acquire the respectability, awe and occasional notoriety accorded medical doctors? A friendlier explanation is that we seek to express ourselves in a way that is complete, accurate, precise and not subject to misinterpretation, and that we find it necessary to rely on excess verbiage and the jargon of our profession to do so. The case also exists for satisfying the patent lawyers, leaving no possible future extensions of our disclosure uncovered. Whatever the reason, engineers are not unique. Every profession worth the designation has devised a cryptic language to communicate among its own members. Coincidentally or not, it helps exclude the uninitiated. How we write is one way to separate ourselves from the general public and from other professions, and even to distinguish the members of our particular technical specialty. When John Pierce of Bell Labs took over as editor of the Proceedings of the Institute of Radio Engineers (the predecessor to the Proceedings of the IEEE), he found he could not understand most of the articles. He asked each member of his editorial board to read an issue of the Proceedings to see if they could understand what they were reading. The answer came back universally that they could not. This exercise helped instigate using specialist reviewers for each Proceedings article, a procedure still in use today.
21
Notwithstanding, we continue to joke about the incomprehensibility of the articles in many IEEE publications. A perennial comment, seeming always to elicit a sympathetic chuckle, is that only its author and possibly one or two of its reviewers can really understand a Transactions paper. Woody Gannett, the staff executive who oversaw publishing the technical journals for both the Institute of Radio Engineers and the IEEE, often told this story: A member submitted a paper to one of the Transactions purporting to describe a revolutionary new circuit component. After due peer review, the paper was published. Only then did the author admit to the hoax. He had described the resistor, but in such a convoluted way that its true identity had eluded the reviewers. Woody was never able to recall exactly when and where the article was published, but generations of his colleagues enjoyed the story, and I still believe it might have been true. Ironically, even those who profess to know good communication when they see it are not immune from the trappings of scholarly publication. In a recent article in the Transactions on Professional Communication, the phrase motivating users to process/engage text-based communication is used. Probably this means motivating users to read, or even to read with interest and comprehension. I am not sure. Engineers have plenty of occasions to write more than just technical papers reports, proposals and operating and maintenance manuals, plus stuff that helps promote and sell what they create. But perhaps Ill save those for a future column, and for the professors who are teaching engineering, writing and marketing to todays undergraduate engineering students. Meanwhile, can you please keep whatever you write a bit shorter, more to the point, and limit your use of acronyms? And as a personal favor, can you find a title for your next journal article that has fewer than 20 words? Thanks. In fairness, I will say that I have both written and criticized technical papers, and I should tell you the latter is much easier. Resources For more on writing, see: J. G. Paradis and M. L. Zimmerman, The MIT Guide to Science and Engineering Communication, MIT Press, 2002. IEEE Transactions on Professional Communication IEEE PCS Newsletter For insights to contemporary engineering jargon, see Technically Speaking, a column appearing periodically in IEEE Spectrum (1981-present).
22
ieee-usa eBooks
Meetings Madness
Why is it that whenever I want to talk to real people instead of sending e-mail, theyre in a meeting? Everyone talks about how to have better meetings. My question is, is there a way to have fewer meetings? Could it make us more productive? Nowadays, more reasons exist to hold more meetings. For example, the IT people hold frequent meetings to bring everyone up to speed on updates (or idiosyncrasies) of the corporate IT system. With nearly every employee a user (or a victim) of the IT system, no alternative is clear. But extra meetings further limit the time available to do ones job. And it disconcerts the customer or colleague who must be told Im in a meeting just now; please leave a detailed message. What detailed message? Callers want person-to-person dialogue, not an exchange of detailed messages. Meetings seem an endless source for horror stories. Take, for instance, the marathon meetings, in which a whole day is dedicated to a series of meetings. To survive such an ordeal, an engineer I know learned to doze off with his eyes partly open. But when he woke up he was sometimes befuddled. Once he made a comment to which his boss replied, Jim, we finished that meeting 10 minutes ago! One of my bosses would hold noontime meetings to critique projects. His secretary would order in sandwiches that we were expected to devour quickly so we could actively engage in critical comments on one anothers projects. Some of us would have preferred a more leisurely lunch in the cafeteria, with shop talk interspersed with discussions about breaking news and sports. Or a game of pinochle with our colleagues as a warm-up to the afternoons creative engineering challenges. Conference calls are supposed to be a good substitute for face-to-face meetings. While waiting for everyone to join the call, youve got an opportunity to talk to someone already on the line about some problem unrelated to the meeting, or about your daughters wedding. But problems abound there, too. Have you noticed that two or three key people might excuse themselves because theyve been called into real meetings by their bosses? Have you then been tempted to say something like Oh, excuse me. Ill be leaving the call. My boss just beckoned. Theyre having a birthday party for the departments newest employee, and I dont want to miss it. I wasnt even going to mention the motivational meetings, for which you and a group of colleagues are dragged away from your computer terminals to spend a day or so folding paper airplanes, or driving a BMW through a cone-filled obstacle course while blindfolded. In the latter, a seeing-eye colleague informs you of oncoming hazards. These types of exercises are intended to make you more of a team player and thus a better engineer... Some Good Meetings I like meetings that have not only an agenda, but also a point. As a young engineer assigned to a production engineering job, I encountered just such a meeting. At the end of each day, the plant manager would hold a meeting of all engineers and production supervisors. He would want the answers to three questions from each engineer. How were the yields today? If any were low, Why? And finally, What is your program to increase yields tomorrow? The meetings were short one half hour at the most, and, by dictate and practice, to the point.
23
Design review meetings are important and can be productive. If they are held too often, however, you may find that a lot of the agenda issues get labeled no change in the post-meeting report. Unfortunately, a string of no changes may be erroneously interpreted as no problem, and a critical issue may be dropped from further consideration, foreshadowing disastrous consequences. Some MBA is always telling us 10 ways to run a good meeting. Im sure MBAs spend a lot of time in meetings, so maybe they know how to run them. But perhaps we are looking in the wrong place for such advice. Consider the New England town meeting. A small town of, say, 5,000 people can make its major decisions in just one evening per year. All interested townspeople are invited to attend, one of the selectmen runs the meeting, and it is over before midnight. Has a selectman ever written an article for the Harvard Business Review on how to run a meeting? Despite the MBAs who say they know how to run a meeting and the New England selectmen who actually do it, I admit to being dubious about my own meeting-running qualifications. With competition from cell phones, laptops, the arrival of the coffee wagon, and conflicting meetings youd rather be in, is it even possible to run an efficient meeting in todays business world? Id like to hear from you. More horror stories are welcome, but Id really like to hear something about the best meeting, or series of meetings, that you have attended or led.
24
ieee-usa eBooks
Whos in Charge Here?

It seems to me that engineers always like to be in charge and in control. History confirms this notion, as do most polls. When we are asked to name desirable job characteristics, we put technical challenge at the top of the list. Then we like to pursue the challenge unencumbered by bureaucratic interference. The bosses we like best are those we perceive as colleagues or mentors. We are optimistic that our technology will be useful to society. Furthermore, we would like to believe our customers will use our ingenious systems as we intend them to be used, not in some dangerous or antisocial way. It doesnt always work out like that. Nevertheless, this inherent desire of engineers to control their work and the way society uses their contributions dates back to the beginnings of the profession. Inventors, entrepreneurs and pioneering electrical engineering leaders promulgated these objectives as both desirable and attainable. A theme soon developed that engineers themselves ought to be in charge of the work they do, and not beholden to some non-engineering-schooled boss. In the extreme, engineering professionalism was defined as not having to take orders from ones employer. The thinking seemed to be that, like physicians, engineers were masters of a body of arcane knowledge that only they could apply for the greater good. Historian Edwin Layton noted that, carried to the extreme, the notion of engineers being in charge even as CEOs of major corporations was tantamount to saying that engineers should control society (not exactly technocracy, but nevertheless embracing many of its elements). One suggestion that might have supported this concept was a cabinet-level department of engineering, with an engineer heading it up. Although suggested more than once around the time of World War I, it never came to be. Would it stand a better chance today? Oddly, the employers and clients drive for profits was seldom mentioned as an overriding factor that would undermine the engineers quest for autonomy. Perhaps this was because many electrical engineers were employed by telephone, telegraph and electric utilities whose customers had no control of rates and no competitive options. However, with the development of consumer appliances and the burgeoning industrial and military markets, the empowerment of players other than engineers (or the engineering profession) made it clear that engineers would do well to consider themselves business community partners, not rulers or adversaries. They also had to be sensitive to customer wants. It became evident that no employer, CEO, board of directors or shareholders committee would buy into the concept of engineering autonomy. It was no surprise, then, to find a paper titled Engineering as an Implement of Management, written by an engineer who had become vice president of Commonwealth Edison, appearing in the American Institute of Electrical Engineers flagship publication in the early 1940s. Even so, another Commonwealth Edison engineer thought the title of the paper could very well have been reversed to read, Management as an Implement of Engineering, reflecting, one supposes, the accelerating interdependence of the two and the ongoing argument about which ought to prevail.
25
Meanwhile, it had become clear that once an engineer had developed and revealed a new technology or product, the genie was out of the bottle. Short of government regulation and enforcement, he or she could not control its misapplication or misappropriation. Our wishes and even promises to the contrary, we could not forestall ill-conceived uses of our technologies by quacks, charlatans, militarists and terrorists. For that matter, we couldnt predict all of the unwanted consequences of our technologies neither unforeseen failure mechanisms nor unanticipated societal effects. In the 1930s, spurred by social scientists opinions, the public blamed engineers for unemployment caused by mechanization of production lines. Stunned by the charges, the engineering community had offered little response beyond promises that technology would ultimately redeem itself by putting even more workers in jobs. Today, some critics are laying any negative societal impacts of television, the Internet, nuclear power and military technology at the doorstep of the engineers who developed the underlying technology. While history has proven that unfettered control by engineers of their own destiny is unrealistic, and the notion of an engineer-dominated technocracy nave, we continue to seek ways to influence bureaucracy and serve society. With astonishingly rapid developments in technology and a diminished ability of engineers to control its applications, a more leavened approach by engineers and their professional societies to whos in charge has evolved. Layton described it as one in which we maintain our moral and ethical obligation to the public interest, while being sensitive to our role as part of the bureaucracy which, he reminded us, our technology helped create! This assignment isnt easy. But it is one that, when successful, enables us to do our duty while we do our job. For More Information For more about engineering autonomy, see: A. Michal McMahon, The Making of a Profession: A Century of Electrical Engineering in America, IEEE Press, 1980. E. T. Layton, Jr., The Revolt of the Engineers, Johns Hopkins University Press, 1986. H. B. Gear, Engineering as an Implement of Management, Electrical Engineering, August 1942. A. S. Bix, Inventing Ourselves Out of Jobs: Americas Debate over Technological Unemployment 1929-1981 (especially Chapter 6), Johns Hopkins University Press, 2000.
26
ieee-usa eBooks
Inside Peer Review

If you want to get a paper published in a journal of some repute, you will encounter the peer review process. To the neophyte, peer review might seem a jungle; to others, a familiar hurdle to surmount. In simple principle, peer review is intended to let only the worthy papers survive, matching the worthiest of them to journals of the highest reputation. Its sometimes forgotten objective is to favor the ultimate reader. The power player in peer review is the publication editor, who selects reviewers and defines acceptance criteria. He or she usually wants the reviewer to comment on the premise of the paper and address these questions: Whats new, and how new is it? Does it follow logically from previous work? Is it believable? Are experimental results well documented? Whats missing? If it is a review paper, is it well organized and historically accurate? Three reviewers seem to be the accepted norm, although in my own experience at IEEE Spectrum I sometimes used as many as 20 reviewers for a staff-generated, multi-viewpoint article. Unless a paper is in the editors own field of interest, he cannot be an arbiter of its technical suitability, but will instead rely on expert reviewers. Invited reviewers who are insufficiently qualified are expected to disqualify themselves. Should an editor find a submitted manuscript far off the mark, he can, if the publications policy permits it, reject it without review. He might be tempted to follow the lead of Harold Ross, the brash founding editor of The New Yorker, and simply dismiss the manuscript with the line, I regret to say we did not like this piece well enough to use it. But the journal editor is likely to feel obligated to let the author of an inferior manuscript down more easily, even if with an invented apology. An editor of a trade publication known to most of us would say something like this: We have received so many articles covering essentially this same topic that we cannot accept another, excellent though it is. On the other hand, if an editor finds it necessary by policy perhaps to have a manuscript that he finds unworthy of publication reviewed nonetheless, he may resort to reviewers likely to agree with him. The process, of course, will be a sham; the editor may even alert the reviewers that he expects no more than a superficial seconding of opinion. In general, such exceptional tactics are unnecessary. Rather, both editor and author hope for thoughtful, unbiased reviews that will help the author correct errors and extend the papers arguments, and so enhance its worthiness for publication. Blind Reviews A journal may have a policy of blind reviews that is, the author will not be told who the reviewers are. A double-blind approach keeps the authors identity from the reviewers as well. In narrow specialties, however, authors and reviewers can sometimes easily guess one anothers identities. An editor may send reviews to the author with or without comment, or, as I sometimes did when editor of Spectrum, send the author only excerpts he deems pertinent. Also, a reviewer might sometimes volunteer to speak directly with an author an offer I would invariably accept. In the same
27
vein, when I received a comprehensive, detailed review, I might encourage the reviewer to identify himself to the author so they could communicate directly. The Job Doesnt Pay Well Reviewers dont have an easy task and usually are not paid for their efforts. Their recompense may come only in what they learn that might enhance their own work. Editors cannot expect reviewers to duplicate research that involves experimentation; at best, they can expect comments on the research methodology. At the same time, reviewers cant be expected to uncover falsifications in reported results. They can, however, confide their suspicions to the editor. Bias and Rejection Editors and authors sometimes suspect a reviewer of bias, to put it kindly. A particularly vicious review might suggest to an editor that a reviewer has fathomed who the author is. (Perhaps the author once voted against tenure for the reviewer!) Most editors will discount a vituperative review and seek a replacement. Academics admit that reviewers often denigrate papers that are based on innovative work but are counter to accepted wisdom; such reviewers seem to want to avoid the publication of contrary scholarship in their journals. As one of them put it, those who review essays for inclusion in scholarly journals know their function is to take exciting, innovative and challenging work by younger scholars and find reasons to reject it. I think this is overly cynical, especially in our fields. Nevertheless, skeptics say with some justification that an author has an advantage if he has been published in the journal before; has co-authored a paper with one of the reviewers; or has favorably reviewed a paper of the reviewer. Furthermore, an overburdened editor feels safer dealing with an established author. Lest I too firmly implant the notion of peer review as fraught with pitfalls and gamesmanship, I should say that I believe most editors, reviewers and authors respect the process for its value in assessing the quality and accuracy of professional journal content. Electronic Publishing Reviews Are a Different Matter Too many variants exist in the time-honored process for print journal peer review to cover in this brief discussion. And many innovative review procedures to deal with the proliferation of electronic publishing are under study. William Arms, a computer science professor and part of a Cornell University team developing the National Science Foundations new digital library for education in the sciences, decries the junk on the web. He notes that while major libraries harbor materials so inferior that it is hard to believe they were ever printed, the problem is even more severe on the web, where the barriers are very low; anybody can be an author and anybody can be a publisher. We hope to discuss some of the approaches to peer review of web-based publishing for a future column.
28
ieee-usa eBooks
Resources For more about peer review, see: Harnad, Stevan, Rational Disagreement in Peer Review, Science, Technology and Human Values, Vol. 10, p. 55, 1985. Arms, William Y., What Are the Alternatives to Peer Review? Quality Control in Scholarly Publications on the Web, Journal of Electronic Publishing, Vol. 8, No. 1, August 2002.
29
Accidents Waiting to Happen

Why do complex systems fail when they shouldnt? Why did the Challenger explode? Why did Columbia disintegrate? Why were large areas of the northeastern United States blacked out in 1965 and again in 2003? Technology historians offer a pair of explanations: 1) Designers are not cognizant of what caused predecessor systems to fail; or 2) They are aware, but are willing to accept risks based on a succession of prior successes. When the Tacoma Narrows suspension bridge (Galloping Gertie) collapsed in 1940 from the effects of aerodynamic phenomena, it was widely reported that the bridge had been perfectly designed for static loads; it was simply that unanticipated effects of wind caused its demise. In fact, an engineering professor at the University of Washington recalled in 1949 that 10 suspension bridges had been destroyed or severely damaged by wind between 1818 and 1889. Brooklyn Bridge designer John Roebling noted in 1841 that storms are unquestionably the greatest enemies of suspension bridges. Fourteen years later he wrote, the catalogue of disastrous [suspension bridge] failures is now large enough to warn against light fabrics, suspended to be blown down, as it were, in defiance of the elements. So, historians believe, the Tacoma bridge disaster should have come as no surprise and could have been averted. Roebling, they say, learned from studying failures; the designers of the Tacoma Narrows Bridge did not. Were they unaware of the suspension bridge failures of the 1800s, or did they consider them too remote for serious consideration? Shuttle Faults In the case of the Challenger, a potential failure mechanism in the form of a propulsion-rocket joint seal that would deteriorate during launch was well known. But successive launches in which NASA got by culminated in the 1986 explosion in which the Challenger and its crew were lost. For many NASA engineers, the cause was easy to guess. In her post-accident analysis, author Diane Vaughan labeled it a case of normalizing deviation. That is, NASA engineers and management were lulled into complacency and some hubris through a string of well publicized, successful launches. After each flight, theyd analyze the degree of joint degradation, but did not eliminate the fault mechanism. They accepted it as normal. When the Columbia disintegrated in February 2003, the cause was found to be another known fault mechanism chunks of foam insulation from the external tanks impinging on the spacecraft. This time, 81 seconds into the launch, a chunk of foam destroyed enough of the vehicles thermal protection shield to cause burning and melting and ultimate break-up of the craft during re-entry. The lead accident investigator said his task force had determined that NASA is not a learning organization. They do not learn from their mistakes. There was no way to monitor any damage to the spacecraft during its mission, nor repair it in flight. The commission called for both in its final report. Power Outages After the great Northeast blackout of 1965, the public was assured that such an event could not
30
ieee-usa eBooks
happen again. Failures would be localized and the offending power company isolated quickly from the grid. That it happened again was a surprise to the public and grist for politicians and the media, but perhaps not that much of a surprise to power engineers. They may have known where the weaknesses lay, but felt powerless in the face of any risk-benefit analysis to do much about it. At this writing, the cause has not been fully defined. Some suggest the grid was not sufficiently automated, others that it was too automated. There is a theory that catastrophes in large systems or major engineering projects occur cyclically. One study revealed a 30-year interval between major bridge disasters in the United States, an interval thought to be the result of a communication gap between one generation of engineers and the next. If valid, this suggests that only the information on successful designs is passed along from one generation to the next, while information about what didnt work and why is not. We can guess why this might be so. We all like to be recognized for our successes, not our failures. Published papers seldom recount failed approaches to an ultimately successful design. Design and development today is commonly done in teams; the consensus vote may be to emphasize successes only. And corporate patent attorneys may prefer to suggest that the path to any successful invention be seen as straightforward, not strewn with miscues or failed approaches. Finally, a company may need to consider pending or potential lawsuits. In his book Design Paradigms, Duke University engineering professor Henry Petroski encourages designers to study past failures. In contemplating new systems or even incremental steps forward in existing systems, the designer should ask how failure can occur and what design changes can obviate that failure mode without introducing another. Petroski warns that once a design becomes accepted, incremental design extrapolation in succeeding generations tends to be the norm and first principles tend to be overlooked. And design decisions that may prove critical are given to less experienced engineers, further fostering the generation gap mentioned earlier. It strikes me that the likelihood of accidents waiting to happen and actually happening will only increase as our systems become more complex. There may be greater hope for boundable systems, like a bridge or a space vehicle, but I worry most about systems that are universal and expansive, yet consist of numerous, potentially fallible, semi-independent pieces like a power grid or, worse yet, the Internet. The burden will rest on future hardware and software designers to prove my projection wrong. I hope they can. Resources For more about design failures, see: J. A. Roebling, Remarks on Suspension Bridges . . ., American Railroad Journal and Mechanics Magazine, Vol. 6, 1841. F. B. Farquharson, Aerodynamic Stability of Suspension Bridges, with Special Reference to the Tacoma Narrows Bridge, University of Washington Structural Research Laboratory, 1949. D. Vaughan, The Challenger Launch Decision, The University of Chicago Press, 1996. T. E. Bell (ed.), Special Report: Managing Risk in Large Complex Systems, IEEE Spectrum, June 1989. T. E. Bell and Karl Esch, The Fatal Flaw in Flight 51-L, IEEE Spectrum, February 1987.
31
H. E. McCurdy, The Decay of NASAs Technical Culture, Space Policy, November 1989. Columbia Accident Investigation Board Final Report, August 2003 (www.caib.us). H. Petroski, Design Paradigms: Case Histories of Error and Judgment in Engineering, Cambridge University Press, 1994.
32
ieee-usa eBooks
Designing Junk
My neighbor was cleaning out his garage when I stopped by. He showed me this huge carton that once must have contained some large appliance. Now it was filled with smaller stuff answering machines, cell phones, VCRs, CD players, fax machines, a computer terminal, and a smoke alarm. Knowing I was an engineer, he asked if I wanted any of it. None of it works any more, he told me. I reached for any defense I could think of, telling him Id never heard of a smoke alarm that didnt work. Did it have new batteries? Yes, but it doesnt work, he assured me. I think the engineers today are designing more junk than ever, he said, in a manner that seemed to exempt me from the otherwise broad condemnation. But that was small solace. I tried to think of some way to defend the profession. Weakly, I pointed out that soon after World War II, executives of some large electronics companies bought into the philosophy that product durability could be anathema to corporate profitability and economic growth. Yes, he agreed, I heard that GE once designed its light bulbs to have a deliberately short life. Im not sure about that, I told him. Later I did a bit of covert research and discovered that, indeed, in the late 1930s, in letters to subsidiaries and licensees, instructions were given to reduce the design life of lamps, in one case from 1000 to 750 hours, and in another from 300 to 200 hours. During this same period, business and trade publications were filled with discussions of the advantages of planned obsolescence of consumer products. There were three ways to go about this. The one most appealing to engineers was that of designing a higher performance product that would make existing ones obviously inferior. This approach is still popular, although it sometimes results in bells and whistles that entice customers but are largely unused. A second approach is designing for wearout or to a targeted life span, the aforementioned light bulbs being one example. In the late 1950s, a Design News editor called for designing to product death-dates. One engineering executive at Whirlpool Corporation agreed, saying that without such an objective some parts of a product might last far longer than others and incur a needless cost penalty in the process. A spokesman for Fairchild Aircraft and Missiles took a more positive approach to the suggestion, saying that knowing the expected service life of the weakest component of, say, an aircraft, is needed as the criterion against which the service life expectancy of every other component is judged. But his argument weakened when he insisted it is wasteful to make any component more durable than the weakest link, and ideally a product should fall apart all at once This philosophy has a classic model in Oliver Wendell Holmes mythical wonderful one-hoss shay, which was said to end its life when all of its parts disintegrated simultaneously. In fairness, major corporations, and numerous engineers, were dismayed at the notion of deliberately degrading all parts of a system to match that of its weakest component. Instead, they focused on upgrading the weak link. Psychological Obsolescence Finally, the third approach to planned obsolescence appeals to the consumers wish to own products that are stylish and, above all, not dated. Termed psychological obsolescence, it may well have its roots in the womens fashion industry, and, later, in the automotive industry. General Motors legendary designer Harley Earl challenged his counterparts in other industries to follow Detroits lead in bring-
33
ing about dynamic obsolescence. Earls image is exploited even today in GM television commercials. Perhaps in reaction to Earls advice, General Electric executives once appealed to his rival, the Ford Motor Co., for recommendations about styling and marketing techniques that might help GE improve profitability of its consumer appliances lines. What to Do with the Junk? How do we dispose of all the obsolete or nonworking consumer products that end up on the curbs of suburbia or in dumpsters when a corporation upgrades its computer system? How much of it can be recycled? What might the environmental impacts be? In Europe alone, electronic waste (e-waste) is projected to reach 12 million metric tons by 2010. The European Union is expected to require manufacturers to take back obsolete computers to keep them out of landfills and to recycle up to 65 percent of them. No End in Sight? The pace of product obsolescence has increased dramatically since the heyday of Harley Earl. Andy Rooney recently noted that his Underwood typewriter lasted 50 years, but complained that when he switched to computers, he needed seven in just six years. The endless spewing forth of new electronic products challenges even seasoned techies to master one before the next comes along. At this point you may suspect that I am really a neo-Luddite. But I consider myself just an average consumer who finds comfort in hardware and software products that dont require servicing, premature replacement, or hours on the phone with a troubleshooter, and dont go out of style before I learn to use them. Incidentally, I politely turned down my neighbors offer of his discarded equipment. The box in my garage is already filled with my own collection of e-waste. Resources For more about planned obsolescence and recycling, see: Packard, Vance, The Waste Makers, David McKay Co., 1960. Stocking, G.W., and M.W. Watkins, Cartels in Action, The Twentieth Century Fund, 1947 (includes excerpts from GE officials correspondence relating to intentional reduction in lamp life). BusinessWeek, 10 Nov. 1956, Industry Studies Auto Styling as Key to Sell New Engineering (Detroits case for changing body styles to provide dynamic obsolescence). Ehrenfeld, J., Designing Sustainable Products/Service Systems, Proceedings EcoDesign, 2001: Second International Symposium on Environmentally Conscious Design and Inverse Manufacturing. Perry, T., State-of-the-Art Recycling Plant, IEEE Spectrum, December 2001. Appelbaum, A., Europe Cracks Down on E-Waste, IEEE Spectrum, May 2002. Perry, T., Recycling in the United States: The Promised Landfill, IEEE Spectrum, May 2002.
34
ieee-usa eBooks
Old Dogs and New Dogs

When I was a neophyte engineer assigned to a development project, I was impressed by the engineer who sat at a desk just outside the department heads glassed-in corner office. The rest of us were assigned to workbenches, the senior engineers having their own benches and the rest of us sharing in pairs. The man in question had a single chair alongside his desk, and it seemed always occupied by one of the other engineers. I soon learned through overheard conversations that he was the department guru. He seemed to attend only those meetings he chose to, and left meetings at will. Someone was always waiting for him in the chair alongside his desk. He could advise you whether to have a piece of microwave hardware machined by a professional machinist, or whether you could do it yourself in the engineers machine shop. Snatches of his advice could be heard: We tried that and the problem was... ;Heres what might work; or That may be worth exploring, but it will be very costly. He knew where important documents were filed, and why, in retrospect, certain proposals had been rejected by a hoped-for customer. From watching this process I learned to ask a lot of questions of the senior engineers and to observe closely what they were working on and how it might relate to my own assignment. Unfortunately and I am a little embarrassed to admit this after I was out of school 10 or 12 years, I began asking fewer questions. Somehow, I began believing I knew more than my associates and sometimes even my boss particularly about the project I was working on. I knew best! And remember, my bosses were getting older; perhaps they were not keeping up with the technology. Later I hesitate to tell you how much later I began to realize my folly. Do you think it may have been when my juniors began coming to me less frequently for my advice? There is no doubt some truth to the saying You cant teach old dogs new tricks. But theres also a bit of truth to the belief that new dogs sometimes resist learning from old dogs. Time may be one reason: it takes time away from working on ones own project to listen to advice. NIH may be another. Engineers thrive on the psychic reward of creating without help. In this regard, Ernesto Blanco, an inventor and adjunct professor of engineering at MIT had this to say: Inventors satisfy themselves finding situations in which a completely different approach appears in their minds to a solution of an existing problem. They dont care how a problem was solved before. They know about it, but they dont respect it very much. There is also the unexpressed fear of some young engineers that knowing about someone elses idea might deflect the radically new thinking that might lead to a breakthrough development. And then theres the legitimate concern that revealing too much to the boss may cause him to instruct you to cease work on your pet project. The seasoned manager will tread a fine line, letting the young pups pursue novel ideas but cutting them off if the path leads to a familiar dead end. Some suspicions and tensions between generations in all walks of life are inevitable. Ours is no exception. But the young dogs and old dogs can complement and learn from one another if both are sensitive to the organizational and social issues. In their recent book Geeks and Geezers, authors Bennis and Thomas suggest that good leaders, regardless of age, share critical traits: adaptability, vision, integrity, unquenchable optimism, and neoteny (a youthful curiosity and zest for knowledge). In the best of all worlds, young engineers will mature into wise and helpful old dogs, like the guru in
35
our department when I was just a young pup. Resources For more about the generation gap, see: Bennis, W. G. and Thomas, R. J., Geeks and Geezers, The Harvard Business School Press, 2002. Howe, N. and Strauss, W., The New Generation Gap, The Atlantic Monthly, December 1992.
36
ieee-usa eBooks
37
1828 L Street, NW, Suite 1202 Washington, D.C. 20036 +1 202 785 0017 www.ieeeusa.org

Best of Backscatter Vol1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Best of Backscatter Vol1

Uploaded by

Copyright:

Available Formats

ieee-usa eBooks

from IEEE-USA Todays Engineer Volume 1

The Best of BACKSCATTER Volume 1

The Best of BACKSCATTER Volume 1

About the Author

The Best of BACKSCATTER Volume 1

ABETS EC2000: Howre We Doin?

The Best of BACKSCATTER Volume 1

Reality and the Virtual Engineer

The Best of BACKSCATTER Volume 1

The Best of BACKSCATTER Volume 1

The Engineer: Professional or Business Practitioner?

The Best of BACKSCATTER Volume 1

About Working Together. . . or Not

The Best of BACKSCATTER Volume 1

The Best of BACKSCATTER Volume 1

Engineers Cant Write? Sez Who!

The Best of BACKSCATTER Volume 1

The Best of BACKSCATTER Volume 1

Whos in Charge Here?

The Best of BACKSCATTER Volume 1

Inside Peer Review

The Best of BACKSCATTER Volume 1

The Best of BACKSCATTER Volume 1

Accidents Waiting to Happen

The Best of BACKSCATTER Volume 1

The Best of BACKSCATTER Volume 1

Old Dogs and New Dogs

The Best of BACKSCATTER Volume 1

The Best of BACKSCATTER Volume 1

You might also like