It's All In a Name

Dr. Dobb's Journal June 2003

For the most part, state legislators aren't unethical, dishonest, or stupid. It just seems like it. In California, for instance, legislators are slashing funds for free lunches for the elderly, while setting aside $226,000 for catered meals for themselves. In Kansas, a state representative wants to cut education funding because she doesn't like a class that's been taught at the University of Kansas for 20 years—even though she's never attended the class, nor spoken with the professor or university officials. And in Tennessee, legislators have banned X-rated videos from cars—unless, of course, the vehicle's windows are tinted.

Meanwhile in Texas, legislators are deciding whether programmers can call themselves "engineers," as in "software engineers." As it turns out, the Texas legislature—known more for its on-the-floor chili-dog fights than its legislation—passed a strict engineering-practices act years ago, requiring anyone with the job title of "engineer" to pass a state licensing exam. To its credit, the current Texas legislature is trying to loosen this requirement so that the 100,000 nonlicensed Texas engineers won't end up in the pokey.

Opposing this move is the Texas Society of Professional Engineers, which has sent cease-and-desist letters to programmers among others who use the title "engineer." To bolster its case, the Society pocketed a former Texas attorney general, who said "The Texas Engineering Practice Act...does not allow an in-house employee of a private corporation, though classified internally as an 'engineer' or under another engineering title, to use the title 'engineer' on business cards, cover letters, or other forms of correspondence that are made available to the public." Currently, the penalty for calling yourself an engineer without having passed an exam results in fines of $3000 per day. Here's hoping the Texas legislature gets it right this time around.

***

For most of us, the term "research and development" refers to the rewarding process of poking around and seeing what you can come up with. Even now, I fondly recall my days as a member of an R&D group, while in fact all I did was write service and user manuals for products ranging from disk drives to compilers. If the truth were known, my being a part of R&D probably had more to do with accounting than engineering.

But "research" and "development" don't always go hand-in-glove. According to the National Science Foundation, there's basic research and there's applied research. The objective of basic research is to gain understanding of a subject without a specific application in mind, while applied research is aimed at meeting a specific need. Then there's development, which is the application of research aimed at producing a thing (http://www.nsf.gov/sbe/srs/seind96/ch4_defn.htm).

What brings all this to mind is Narain Gehani's recently released Bell Labs: Life in the Crown Jewel (Silicon Press, 2003; ISBN 0-929306-27-9). Gehani was, for 23 years, a member of the technical staff at Bell Labs, specializing in software research. Among other accomplishments, Gehani codeveloped the Concurrent C programming language (see "Concurrent C for Real-time Programming," by N.H. Gehani and W.D. Roome, DDJ, November 1989). What's most interesting about Gehani's book is his description of the organizational maturation of Bell Labs from its founding in 1925. From the outset, support for basic research was, according to Gehani, "ingrained in the AT&T culture." Researchers were free to select their own research topics without worrying about business relevance. Putting its money where its mouth was, 10 percent of the Bell Labs R&D budget was allocated for basic research, and research was separated from AT&T business units by invisible walls. The result was innovation like the world had never seen before, or will likely ever see again. While we're familiar with UNIX, C, C++, and transistors, it is amazing that the average home probably has 25 devices based on Bell Labs technologies—everything from phones and TVs, to CD players and remote controls.

Alas, things started to fall apart with the divestiture of government monitored AT&T monopoly, as profit pressures shifted to the operating units and long-range research was pushed aside for short-term market-oriented R&D. But then, that's commonplace with most research these days. In general, R&D spending for computer hardware companies averages between 5 to 10 percent of sales, while 10 to 20 percent for software companies. But pegging R&D spending to sales can be misleading because, if sales drop, it follows that R&D spending does, too. Nevertheless, companies that understand the importance of R&D and can afford it continue to invest. Microsoft, for instance, increased R&D spending to $5.2 billion in 2003, up 20 percent over 2002.

That said, most of today's research is applied research, with products and profit in mind. Granted, this is better than nothing, but like Bell Labs' Dennis Ritchie said 20 years ago in his Turing Award Lecture, "the greatest danger to good computer science research today may be excessive relevance." You bet, and it still holds true today.


Jonathan Erickson
editor-in-chief
jerickson@ddj.com