One fine business afternoon early in 1990, when we still used wires and microwave towers to make phone calls, and almost all long-distance calls went through big AT&T switches, one of the 100 or so 4ESS switches that handled U.S. long-distance traffic at the time hit a glitch and executed some untested recovery code. The switch went down briefly. No biggie, since traffic automatically took other routes, but in the process the initial switch that hit the glitch dragged its neighboring switches down, and the process cascaded across the country, as all the switches that handled long-distance traffic began to repeatedly crash and auto-recover. The result was that hardly any public telephone customer in the U.S. could make a long-distance phone call that afternoon, along with millions of dollars of time-sensitive business lost.
AT&T tried to contain the damage by rebooting the misbehaving switches, but as soon as a switch was brought back up, a neighboring switch would tell it to go down. The engineers at AT&T’s R&D arm, Bell Labs, who wrote the switch programs, were called in, and, by the end of the day, network normality was restored by reducing the network message load.
An investigation was launched immediately, and after digging through a few hundred lines of code, word-of-mouth within Bell Labs was that the culprit was a closing brace (}) that terminated a selection construct—but the wrong one. The lawyers at Bell Labs quickly claimed such a lapse of human frailty could never be avoided entirely, and so dodged any potential lawsuits.
The lawyers were right; the intrinsic nature of software is such that the total absence of bugs is never guaranteed. But the simple practice of tagging all closing braces (or end in some languages) with a brief comment that indicates which construct they are closing would go far toward eliminating such an error; for example, instead of just writing '}' all by its naked self, write } //for, or } //if, or whatever.
Tagging construct terminators can be done without changing existing compilers, and since such construct terminators usually appear on a line of code by themselves, the structure of the code is not affected. All this does is make the code easier to understand and helps prevent bugs like the one just described. This practice is especially helpful when code must be moved about, which happens often. In addition, if coders want to go one step further in making their code understandable, a brief comment can be added after the tag, like this
}//for all transactions over a thousand dollars
This would also eliminate the usefulness of putting the opening brace on a line by itself where it would be separated, from a syntactic viewpoint, from the construct it is punctuating, while creating an almost blank line that could better serve to separate logically distinct parts of a program.
I thus propose adoption of this practice by all software engineers and coders forthwith, as well as taught to all beginners from the get-go.
A. Frank Ackerman, Butte, MT
Surprisingly Deep Roots of Word Processor Interface Design
The Research Highlight "Soylent: A Word Processor with a Crowd Inside" by Michael Bernstein et al. (Aug. 2015) reminded me how long software developers have been pursuing such basic concepts as reducing redundancy and improving readability in computer-generated text. Soylent recruits volunteer humans via the Web, through a novel form of crowdsourcing, to accomplish what has long been a goal for natural language processing—improving readability and reducing redundancy in computer-produced text. Early work on automated abstracting, as in Betty Mathis et al.’s 1973 article "Improvement of Automatic Abstracts by the Use of Structural Analysis" in the Journal of the American Society for Information Science, demonstrated an algorithm that improved readability. Mathis et al. cited 18 even earlier works, including those covering algorithms showing how to shorten abstracts by removing redundant and/or unnecessary phrases. Their earliest citation was to a 1958 paper by IBM’s Hans Peter Luhn "The Automatic Creation of Literature Abstracts" in the IBM Journal of Research and Development, demonstrating the deep roots of automated text generation.
Charles H. Davis, Bloomington, IN
CS Quantity Is Not CS Quality
Moshe Y. Vardi’s Editor’s Letter "Incentivizing Quality and Impact in Computing Research" (May 2015) was the first public acknowledgment I have seen of the problem of how to quantify quality in computer science research, as well as in applied computer science; that is, numbers alone do not determine quality. The belief in quantity-quality equivalence appears to have so permeated the computer science culture it is not uncommon to use quality numbers to cover real problems in research and software development. An instance I can cite from my own experience is the number of regression tests performed in software development despite the outcry from developers that most such tests add no value and in fact hinder development. I can only hope the realization of the problem of covering inferior research and practice with inflated numbers of published papers and software projects completed trickles down to the trenches of software development worldwide.
Raghavendra Rao Loka, Palo Alto, CA
Liability in Software License Agreements
Vinton G. Cerf’s "Cerf’s Up" column "’But Officer, I was Only Programming at 100 Lines Per Hour!’" (July 2013) asked for readers’ views on how to address current software quality/reliability issues before legislative or regulatory measures are enacted. The lion’s share of the "persistent lack of software quality" problem lies not with software "professionals" but with business managers at software companies rushing to ship software well before it is ready for public consumption. There are few direct negative consequences for such decisions and far too many positive consequences, including the business mantra "First to market wins regardless of product quality."
I still see nothing to alter this bleak landscape until society as a whole becomes so fed up with the sad state of software it finally enacts laws making it illegal for software vendors to disclaim liability in their license agreements. Such drastic measures would have immediate consequences: Most vendors would go out of business rather than face the legal and financial music of their past transgressions; the price of software would instantly jump by a factor of 5 to 50; development and delivery schedules would expand; software prices would vary by customer, reflecting the liability risk posed by the customer; and, as always, lawyers would continue to win, even as their clients lose.
Many software developers would lose their jobs, but those among them able to design, structure, and implement software in a reliable manner would be in demand and earn much higher salaries, especially if the title "professional" meant they were personally liable for any possible failure of software they approved. However, much of the higher salary would go to cover "professional insurance" premiums.
In many jurisdictions, those in the licensed construction professions have the power and legal authority to deny their signatures when appropriate, halting construction until the related flaw is corrected, and management cannot legally circumvent the process.
How many software professionals wield such power over their own products? Until they have the authority, the primary problem for flawed software products will continue to reside outside the technical field of software development and computer science.
One hopes there would be a legal exception from liability for software that is free and/or open source. Freedom from liability could actually be an incredible stimulus for the free/open-source software market.
David Warme, Annandale, VA
Whose Calendar?
In Leah Hoffmann’s interview with Michael Stonebraker "The Path to Clean Data" (June 2015), Stonebraker said, "Turned out, the standard said to implement the Julian calendar, so that if you have two dates, and you subtract them, then the answer is Julian calendar subtraction." I surmise this was a lapsus linguae, and he must have meant the Gregorian calendar used throughout the former British Empire since 1752.
Marko Petkovšek, Ljubljana, Slovenia
Author’s Response
I thank Petkovšek for the clarification. The two calendars are, in fact, different, and I meant the Gregorian calendar.
Michael Stonebraker, Cambridge, MA
Join the Discussion (0)
Become a Member or Sign In to Post a Comment