ChipCenter Questlink
SEARCH CHIPCENTER
Search Type:
Search for:




Knowledge Centers
Product Reviews
Data Sheets
Guides & Experts
News
International
Ask Us
Circuit Cellar Online
App Notes
NetSeminars
Careers
Resources
FAQ
EE Times Network
Electronics Group Sites

  Analog Avenue

    Editorial

Editorial Archives | Feedback

Not For Public Consumption
by Paul McGoldrick

It has been my good fortune not to have attended any meeting with software engineers for nearly ten years; I hadnýt realized that until I was invited to sit in at a benefits meeting at my spouseýs company a short while ago. The one software engineer present was a hoot.

Not hoot as in funny; rather in that he was obviously not safe to be let out among other people; he dominated the meeting with pompous questions; didnýt get it when the answers came; repeated questions using "big" words; explained why he had asked the question after he eventually got the answers. Ouch! I am so glad that I donýt have to live with that all day anymore, as I did when I ran an engineering development group.

The public corporation that owned the manufacturing company I worked for had no other like it within its umbrella; most of the groups did things in defense (or offense, depending how you look at it) and of the few who could actually talk about what they did was an operation that did "Ground Zero" simulations -- what would happen when an X kiloton nuclear warhead was exploded Y hundreds of feet above ground zero: How many would die, how many would just fry, how many would live a year, and the most important question: How much damage to the infrastructure? Really ugly stuff.

But the software engineers working on this stuff were like cubicle-held zoo animals; most of them would be quite happy to sit for 24 hours at a time in front of their Tempest-proofed computers and be fed at intervals through a slot.

I think the software engineerýs tortured way of talking, writing and working, which I cannot understand, is why code these days takes advantage of the memory available. It is said by those supposedly in the know that the complete breadth of Windows, for example, is not understood by any single individual any more. The argument is used to point towards a crash in the ability of the operating system to grow in any meaningful way in future versions.

We are all biased in some way so I looked to see whether there existed any written, non-code, examples of the convolutions of the software community. I found one almost immediately. The IEEE Computer Society and ACM have a joint task force that has produced The Software Engineering Code of Ethics and Professional Practice. Itýs a doll. The short version occupies two pages, but the "Full" version is thirteen pages in length. What would take a reasonable technical writer a couple of paragraphs runs on and on and on.

The reason for the length -- and presumably an encouragement to read the full version -- is given in the preamble to the short version:

"The short version of the code summarizes aspirations at a high level of abstraction; the clauses that are included in the full version give examples and details of how these aspirations change the way we act as software engineering professionals. Without the aspirations, the details can become legalistic and tedious; without the details, the aspirations can become high sounding but empty; together the aspirations and the details form a cohesive code."

What wonderful thought loops! I did ask my wife if the particular engineer (at her meeting) went to trade shows but, no, heýs not let out by the company.

Analog Main | Product of the Week | Columns | Editorial | Tech Notes

Click here to get your listing up.

Copyright © 2003 ChipCenter-QuestLink
About ChipCenter-Questlink  Contact Us  Privacy Statement   Advertising Information  FAQ