News & Analysis

Academics, pundits don't have a clue what it's like for working EEs

5/15/2006 9:00 AM EDT

Regarding the interview with professor Geoffrey Orsak ("Seeding new crop of innovators," April 10, page 24), I wondered whether Orsak and EE Times readers caught the fundamental contradictions in the U.S. government's meddling with the domestic EE jobs market--and whether anyone else was offended at being reduced to the status of a "crop."

On the one hand, Orsak lobbies hard for more Congress-approved funding for public-school engineering education; on the other, he is mute on the coming flood of Congress-approved H-1B visas and their consequent wage-depressing effects on the domestic engineering market.

Why should young Americans be thrilled about careers that mostly lead to Dilbert-style cubicle dwelling? Or ones that have featured stagnant wages for the past six years? Or ones that are regularly exported at the stroke of a key to cheap labor pools abroad?

I submit that Orsak, like most tenured academics and self-styled visionaries, has not recently or perhaps ever held a line engineer job. I see no evidence that their claims and conjectures, put into action, would have any effect in reversing the extinction of the U.S. engineer. I also fail to see why I should mind anyone so glaringly out of touch with job market realities.
Alex Templeton, CTO
Brown Crow Inc., Seattle

SDR techniques are already bringing real benefits

Rick Merritt's coverage of the Software Defined Radio Forum meeting (April 17, page 1) was interesting and informative, but I think he missed a key point.

SDR techniques are being deployed by virtually all radio manufacturers today in all sectors to the maximum extent possible--and have been for at least 10 years. Admittedly, RF flexibility has been an issue, but even this is improving. As an example, cellular has a finite number of bands in use internationally. Typically, a cell phone uses two power amplifiers and four low-noise amplifiers for a quad-band phone. Within these bands, DSP software can be used on common baseband platforms to address and upgrade the various waveforms, such as W-CDMA, HSxPA and, eventually, LTE. Standard implementation deficiencies, misunderstandings and errors are almost totally corrected via SDR upgrades today. SDR-centric techniques are providing significant benefits today.

The press should pick up on the fact that significant SDR-centric benefits are currently available in the baseband and that desired RF flexibility is improving, though it still needs significant R&D initiatives.

Moore's Law does not apply to RF, mixed-signal, etc.; advances there are slower to emerge.
Jim Gunn
Principal
JGunn Research
Richardson, Texas

Digital artists have stuck with FireWire because it works

Loring Wirbel's Opinion piece "Mac artistes, get with the times" (May 1, page 4) takes a needless jab at the digital art community. This community is often an early adopter, but with FireWire the situation is different. Almost every piece of high-end AV hardware works with FireWire, and so does Apple's Final Cut Pro. You'd have to wonder why anyone would be eager to switch to a new technology (Ethernet) that, so far, has never been used for AV and exists on no AV products that I'm aware of.

FireWire's multipoint-to-multipoint capabilities suit it for on-location work or for any device network that frequently changes. Ethernet requires infrastructure, adding cost and complexity. I need only point to another article in the same issue ["1394 primed for home net revival," page 1] to show that FireWire still has merit and might yet deliver on its promise as a pervasive network for AV components.
John P. Norair
Design Engineer
Proximities Inc.<
Melbourne, Fla.

For bug-free software, develop the model first

"Embedded experts: Fix code bugs or cost lives" (April 10, page 1) overlooked bugs that happen because nobody understands the code. Every bug I have ever seen was coded perfectly and executed perfectly. It was a bug because it was the wrong code in the wrong place.

The cheapest way to develop and maintain relatively bug-free software is to develop the model first, and then make no code changes--ever--without first changing the model. Code is valid if and only if it perfectly implements the model. Using this criterion, "inspecting code" is easy and meaningful.

In my 20 years of programming in the private sector, I have yet to see a management-driven software initiative where design discipline was a priority. Until that is addressed, the problem will worsen.
Spencer Doidge
Software Engineer
Applied Scientific Instrumentation
Eugene, Ore.


print

email

rss

Bookmark and Share

Joinpost comment




Please sign in to post comment

Navigate to related information

Product Parts Search

Enter part number or keyword
PartsSearch

FeedbackForm