ac.il/~nachumd/horror.html) showing why the facts can no longer be ignored. Moreover, certification standards like CMMI do not work. I have been part of CMMI-certification drives and find that real software-development processes have no relation to what is ultimately certified. Software development in real life starts with ambiguous specifications. When a project is initiated and otherwise unrelated employees assembled into a team, the project manager creates a process template and fills it with virtual data for the quality-assurance review. But the actual development is an uncontrolled process, where programs are assembled from random collections of code available online, often taken verbatim from earlier projects.

Most software winds up with an unmanageable set of bugs, a scenario repeated in almost 80% of the projects I’ve seen. In them, software for dropped projects might be revived, fixed by a new generation of coders, and deployed in new computer systems and business applications ultimately delivered to everyday users.

Software developers must ensure their code puts no lives at risk and enforce a licensing program for all software developers. Proof of professional discipline and competency must be provided before they are allowed to write, modify, or patch any software to be used by the public.

As suggested by Parnas, 1, 2 software should be viewed as a professional engineering discipline. Science is limited to creating and disseminating knowledge. When a task involves creating products for others, it becomes an engineering discipline and must be controlled, as it is in every other engineering profession. Therefore, software-coding standards should be included in penal codes and country laws, as in the ones that guide other engineering, as well as medical, professions. Moreover, software developers should be required to undergo periodic relicensing, perhaps every five or 10 years.

Basudeb Gupta, Kolkata, India

References

1. Parnas, D.l. licensing software engineers in Canada.

Commun. ACM 45, 11 (nov. 2002), 96–98.

2. Parnas, D.l. software engineering: an unconsummated marriage. Commun. ACM 40, 9 (sept. 1997), 128.

unicode not so unifying

Poul-Henning Kamp’s attack in “Sir, Please Step Away from the ASR- 33!” on ASCII as the basis of modern programming languages was somewhat misplaced. While, as Kamp said, most operating systems support Unicode, a glance at the keyboard shows that users are stuck with an ASCII subset (or regional equivalent).

My dubious honor learning and using APL* while at university in the 1970s required a special “golf ball” and stick-on key labels for the IBM Selectric terminals supporting it. A vexing challenge in using the language was finding one the many Greek or other special characters required to write even the simplest code.

Also, while Kamp mentioned Perl, he failed to mention that the regular expressions made popular by that language—employing many special characters as operators—are virtually un-intelligible to all but the most diehard fans. The prospect of a programming language making extensive use of the Unicode character set is a frightening proposition.

William hudson, Abingdon, U.K.

*aPl stands for “a Programming language,” so “the aPl programming language” deconstructs as “the a programming language programming language.”

the Merchant is still Liable

In his Viewpoint “Why Isn’t Cyberspace More Secure?” (Nov. 2010), Joel F. Brenner said that in the U.K. the customer, not the bank, usually pays in cases of credit-card fraud. I would like to know the statistical basis for this claim, since for transactions conducted in cyberspace the situation in both the U.K. and the U.S. is that liability generally rests with the merchant, unless it provides proof of delivery or has used the 3-D Secure protocol to enable the card issuer to authenticate the customer directly. While the rates of uptake of the 3-D Secure authentication scheme may differ, I have difficulty believing that difference translates into a significant related difference in levels of consumer liability.

The process in the physical retail
sector is quite different in the U.K. as
a result of the EMV, or Europay, Mas-
terCard, and VISA protocol, or “Chip &
PIN,” though flaws in EMV and hard-
ware mean, in practice, the onus is
still on the bank to demonstrate its
customer is at fault.

author’s Response:

The U.K. Financial Services Authority took over regulation of this area November 1, 2009, because many found the situation, as I described it, objectionable. In practice, however, it is unclear whether the FSA’s jurisdiction has made much difference. While the burden of proof is now on the bank, one source (see Dark reading, Apr. 26, 2010) reported that 37% of credit-card fraud victims get no refund. The practice in the U.S. is not necessarily better but is different.

Joel f. Brenner, Washington, D.c.

format Migration or
unforgiving obsolescence

David S.H. Rosenthal’s response (Jan. 2011) to Robin Williams’ comment “Interpreting Data 100 Years On” said he was unaware of a single format widely used that has actually become obsolete. Though I understand the sentiment, it brought to mind Apple’s switch from PowerPC to Intel architecture about six years ago. Upgrading the computers in my company in response to that switch required migrating all our current and legacy data to the new format used by Intel applications at the time. Though we didn’t have to do it straightaway, as we could have kept running our older hardware and software, we had no choice but to commence a process to migrate over time.

This decision directly affected only my company, not the entire computing world, but when addressing data exchange and sharing, it was an additional factor we had to consider. Rather than face some general obsolescence, we may inevitably all have to address format obsolescence that is a natural consequence of IT’s historically unforgiving evolution.

Bob Jansen, erskineville, nSW, Australia

Communications welcomes your opinion. to submit a letter to the editor, please limit your comments to 500 words or less and send to [e-mail].

© 2011 aCm 0001-0782/11/0300 $10.00