Forum

The front portion of "Forum" features responses to the "Viewpoint," "Not Now Not Like This" (Feb. 2000, p. 29), regarding the ACM Council’s decision to not endorse the licensing of software engineers.

I think it is unfortunate that the Council concluded that ACM’s involvement in licensing efforts would be viewed as an endorsement of such efforts. I believe more states will move toward licensing, and legislators and licensing boards will need guidance from software engineering professionals and professional societies as they go through that process. The Council seemed to take the view that refusal to provide advice and guidance to licensing efforts will somehow prevent them from occurring. Licensing will occur regardless of whether the ACM contributes guidance.

Meaningful certification of software engineers by professional societies could provide a viable alternative to licensing, but the snail’s pace of the original ACM/IEEE joint task force most likely contributed to the decision to license software engineers in Texas, as well as a delay in any form of certification. Also, the ACM Council may believe any form of certification is premature. But more widespread licensing is inevitable. Legislators and lawyers won’t wait for us to decide when our profession is sufficiently mature for software engineers to produce safe and reliable products.

Nancy Mead
Pittsburgh, PA

Computers, and ACM, have been around over 50 years, and for at least half that time computers have controlled medical equipment, lethal weapons of war, large industrial machines, passenger planes and trains, and human-carrying rockets with a rather remarkably good safety record. Some people know building codes for programs, as well as how to write safe ones. A quick look in the ACM digital library under "reliability" and "software" shows 34 articles, including one from over a decade ago, titled "Yes, Software Reliability Can Be Measured and Predicted." It may be true that "much more research is needed" to improve our building codes and software engineer training, but our society’s dependence on computer software does not allow an indefinite wait while researchers proceed, at the rate of a few articles a year, to study the question.

I look forward to future task force reports, so the ACM can rejoin the real-world process of assuring safe software.

Thomas W. Moran
Saratoga, CA

I was disappointed by the position taken by the ACM on licensing software engineers. Though I agree with many of the Council’s findings and concerns, I disagree with its conclusion.

If one had to distill a common theme out of the variety of licensing/governing measures that traditional engineering disciplines follow, it would be: "First and foremost, be accountable to the public in all your engineering activities." I realize the ACM is not an engineering organization, but I had hoped it would have acted in the spirit of this theme. The decision to withdraw from working with licensing boards—because licensing is premature and we don’t have complete answers to our questions—is not being accountable to the public. This is analogous to a doctor refusing to be part of a patient’s treatment of an unknown disease, because he or she doesn’t know all the answers and needs more time to conduct research before prescribing a treatment. Sooner or later, the patient will die or resort to less desirable sources for treatment. Ready or not, software activities are going on in safety-critical areas, and this decision is tantamount to putting our heads in the sand.

Indeed, "licensing software engineers provides no guarantee of software quality." My reply: "Not licensing software engineers encourages no guarantee of software quality." (Besides, software guarantees these days are really liability statement disclaimers.) If I recall correctly, the catalyst for starting the Professional Engineers of Ontario was a janitor being electrocuted when he plugged an appliance into an improperly wired outlet. Software systems have been responsible for a number of deaths already; how many more people is our profession going to kill through negligence before measures are adopted to govern it? Yes, licensing measures are premature, but we can’t limit ourselves to standing in the background to conduct more research when we could be lending our knowledgeable assistance to efforts directed at increasing the public’s safety.

Boehm sums it up very well in the Council’s statement: "Premature licensing should not be endorsed by ACM, but ACM should work with sponsors of premature licensing to minimize attendant damage, and should work toward establishing appropriate licensing capabilities." This would be a socially conscious direction to take.

Jason Steffler
Kansas City, MO

I am opposed to the licensing of software engineers and other software workers or creators. Part of my reason is purely personal. I have been a computer programmer for about 20 years, and for approximately half that time I have been a consultant, not an employee. If the state in which I reside was to pass a law forbidding me to continue as a consultant, the nature of the work I do would probably not change, as I would likely become an employee. My understanding is most—if not all—states that license engineers have exemptions for manufacturers and other companies that do not represent themselves as engineers.

My view is that the ACM should not cooperate in any way with efforts to license software workers and should in fact condemn such efforts because:

Licensing efforts won’t accomplish what state legislators claim and are therefore the furtherance of an untruth. This is contradictory to section 2.7 of the "ACM Code of Ethics and Professional Conduct" (www.acm.org/constitution/code.html) which states in part: "This imperative implies an obligation to counter any false views related to computing."
The law in Texas will probably not be enforced, because if Texas tried to enforce it, it would probably put an end to sectors of the state’s economy. Many companies and individuals would simply find a jurisdiction where they could continue their business untouched by the law. This jurisdiction might be another state; it might even be another country.
Laws that aren’t enforced tend to be misused, that is, enforced selectively.
Any selective enforcement will probably fall on people who are consultants, who have only limited means to defend themselves from such abuse, and will be effectively silenced by the mere existence of such a law, a worrisome breach of First Amendment rights.
Such a law will reduce opportunities in times of economic stress by limiting the rights of companies to hire people as consultants, sometimes done prior to actual hiring, or sometimes because the company doesn’t have the resources to hire.
The law is likely to limit the ways industry and academia interact.

These points made, I do want the ACM to continue to investigate issues of software reliability. These issues affect us all. However, a legislature cannot wish these issues away by granting licenses.

Anonymous
Address withheld

Electronic Identity Theft

I enjoyed Hal Berghel’s discourse regarding identity theft in the Net age ("Social Security Numbers, Identity Theft, and the Web," Feb. 2000, p. 17).

What is needed to diminish this threat is a greater understanding of the roles of identification and authentication. It appears that outside the intelligence world and the hardcore computer world, the distinction is blurred.

An identifier is a piece of information used to distinguish data. An authenticator is a piece of information used to establish authority. My name, William Dan Terry, identifies me and any information regarding me. My signature authenticates (disregarding the issue of forgery) that I personally acknowledge the terms of the document I sign. A username identifies my computer account. A password authenticates my authority to use that account.

Berghel points out the social security number was created to be used as a primary identifier within the Social Security Administration. Its use within and without the SSA wouldn’t pose much of a threat if it wasn’t also used as an authenticator. A person’s SSN wasn’t really designed to be private. Any private information identified by an SSN shouldn’t be disseminated just because the SSN is identified. It should require the authentication of authority or privilege before being disseminated.

My favorite peeve is the use of my mother’s maiden name. It is a matter of public record and has never been considered something that should be private. Yet that piece of information unlocks my credit card information when I call the credit card company.

While there’s debate over how private an SSN should be, the fact is it was designed as an identifier. Without its use to identify publically available information, the publically available information could still be gathered. It might just take some additional effort.

Identifiers can be public. They can be shared. But they should never be used for authentication. The crux is to retrain all of the services maintaining information that should be private to cease using publically available information for authentication. Then, and only then, do we have a chance to fight identity theft.

William Dan Terry
Fort Collins, CO

Berghel routinely writes very insightful and enjoyable "Digital Village" columns. His recent one on SSNs and identity theft is especially topical, given the dramatic increase in identity theft and other privacy concerns related to the Web. In fact, since his column was published, the recent DoubleClick PR debacle has focused even more attention on this matter. I really enjoyed Berghel’s perspectives and read the piece twice.

It always amazes me that so many individuals simply accept the status quo without serious consideration of the real impact of technological changes on their personal lives.

I also value the well-documented history and background of the use of SSNs by the government and others as a primary key. The legal issues are fascinating for lawyers and non-lawyers alike. The URLs included in the column are a very useful resource for all of us.

I plan to make this required reading in my e-commerce courses this year. I have no doubt it will stimulate engaging class discussions each time.

Kudos to Communications for publishing timely and thought-provoking articles.

Merrill Warkentin
Boston, MA

Berghel presents a hypothetical argument in which one side takes the position that "the U.S. Constitution makes no mention of any right to privacy in the first place …"

But this cannot be sustained: Although the word "privacy" is not used, Amendment Four explicitly requires that the federal government defend the right of all to be secure "in their persons, houses, papers and effects … against unreasonable searches …"

One might argue that email or Web transactions occur over a public conduit, the Internet. However, the right to privacy of electronic files or other data before and after transmission certainly would seem to be protected by the Constitution.

Furthermore, one might argue that only the addressing and routing on the Internet is public, and that the content of any data packet or file is protected, as are private papers in a sealed envelope. That the envelope (email header, for example) happened to be of thin paper and easily seen through would not be relevant to the constitutional guarantee of security.

Amendment Four, by the way, is not alone: Amendments Nine and ten imply that because the federal government has not been allowed explicitly to confer or deny privacy, a right to personal privacy is one reserved to the people, while a right of privacy of the States, is reserved to the States.

John Michael Williams
Redwood City, CA

Email-Only Classes

I am happy to have received so many responses regarding my "Viewpoint" ("Can a Course be Taught Entirely by Email," Sept. 1999, p. 29) in the February "Forum." I’d like to address the issues raised in these responses.

My "Viewpoint" refers strictly to email-only courses—courses that do not use any other medium for instruction. Distance education that uses a combination of mediums to enrich content and delivery is desirable and perhaps essential in many cases.

Email-only is a rudimentary technology for teaching, especially when these courses can be supplemented easily by chat rooms and discussion forums, as cited by De La Vega (Sept. 1999, p. 12) in his experience of using BioMOO. In fact, MOOs (multi-user object-oriented), MUDs (multi-user dimension), and LARP (live action role play) environments (systems and programs) that allow multiple users to connect to shared set of virtual rooms, where they interact with each other in real time, have been in existence for quite some time now.

Email-only courses have potential for limited and specialized applications, like the one cited by Decker (Sept. 1999, p. 11) or where the audience is specialized. Even here, the quality of instruction would have increased tremendously had these courses been supplemented by other media like compressed video or chat rooms.

Shallit (Sept. 1999, p. 13) is confusing the medium with the message. Email or any other medium or technology is a tool that should be well tested before being used on a mass scale. Certainly, neither the Wright brothers nor NASA started transporting people on planes or arranging space trips until the aviation technology had matured enough to be safe. In academia, we should use the same norms used for items supplied for mass public consumption. For example, any new drug goes through extensive testing and FDA approval before being released to the public.

There are differences between email-only courses and correspondence courses; one is examination. Traditionally, even though a student may take correspondence courses, the exams are proctored; in email-only courses the exams are by email. Moreover, correspondence courses have text, pictures, and diagrams that may be all together in the same place on a paper to explain a concept—a feature email-only courses don’t have.

Finally, an email-only course or degree has both the components education (teaching and learning) and certification (course grade, diploma, and so forth) as any other university course or degree, hence my objection to email-only courses.

Vir V. Phoha
Tahlequah, OK

Sign-Off on Y2K

We have been witnesses over the past seven years to a rather extraordinary phenomenon: A seemingly trivial shortcut in digital date recording turned out to have the capacity to bring our information infrastructure to its knees.

An alarm was sounded and resounded, and organizations everywhere rallied to make necessary changes. The total effort thus assembled was more than a million person-years of effort, all of it pretty efficiently coordinated and directed toward essential remedies for the problem. Now that the Y2K computer-problem dust has settled, it is clear the effort has been a success, a complex necessary step to avoid what could have been a catastrophe. After we’ve all patted ourselves on the back for whatever role we played, let us give credit to two people who provided an effective catalyst for the effort: Peter de Jager and Ed Yourdon. De Jager and Yourdon were among the first to identify the Y2K computer problem. More important, they stayed the course; they were the ones who patiently cajoled managers around the world to focus and stay focused on Y2K. In retrospect, the Y2K computer problem was never a technical challenge; it was rather a challenge to our organizational capacity. It was De Jager and Yourdon who met that challenge and kept us organized. Without their efforts, 2000 could have turned out very differently.

Vic Basili,
Fred Brooks,
Tom DeMarco,
Ernst Denert,
Koichi Kishida,
Manny Lehman,
and Elliot Soloway