I appreciated Phillip G. Armour’s use of coupled pendulums as an analogy for software project management in his The Business of Software column “The Chaos Machine” (Jan. 2016) but would like to set the record straight on a few technical points. Chaos is already being exhibited when Armour’s machine performs smoothly, in the sense future behavior is inherently unpredictable. What happened when the machine made a hop was not that it “hit a chaos point” but apparently some “resonance disaster” that caused it to exceed the range of operation for which it was built. Moreover, “turbulence” is not an appropriate description in this context, as it describes irregular movement in fluid dynamics. Chaotic behavior does not require three variables. The most basic instance—the double pendulum, with one rod hanging from the end of another rod—involves only two variables. And the technological solution for chaos is “control,” which applies to software project management as well. Setting a project in motion, even one as simple as a single pendulum, then leaving it unattended, is not a good idea. A good case in point for how an unattended project can become chaotic is the construction of the new Berlin airport.
Günter Rote, Berlin, Germany
Author’s Response:
Rote’s point is well taken. The word “chaos” in general usage simply connotes disorder and unmanageability, and I was using that meaning rather than a more formal characterization—something beyond both my skill and my intent. Showing the device generated a lot of interesting discussion in the workshop—which was the point. And as Rote graciously acknowledges, it was an analogy for software-project management rather than a physics experiment.
Phillip G. Armour, Deer Park, IL
We Are Our Machines
I was encouraged by Communications addressing such weighty issues as “lethal autonomous weapon systems” through Moshe Y. Vardi’s Editor’s Letter “On Lethal Autonomous Weapons” (Dec. 2015) and related Stephen Goose and Ronald Arkin “Point/Counterpoint” debate “The Case for Banning Killer Robots” in the same issue. Computing professionals should indeed be paying attention to the effects of the software and hardware they create. I agree with those like Goose who say use of technology in weapons should be limited. America’s use of military force is regularly overdone, as in Iraq, Vietnam, and elsewhere. It seems like making warfare easier will only result in yet more wars.
ACM should also have similar discussions on other contentious public issues; for example, coal-fired power plants are probably today’s most harmful machines, through the diseases they cause and their contribution to climate change.
ACM members might imagine they are in control of their machines, deriving only their benefit. But their relationship with machinery (including computers) is often more like worship. Some software entrepreneurs strive even to “addict” their users to their products.1 Computing professionals should take a good look at what they produce, not just how novel or efficient or profitable it is but how it affects society and the environment.
Scott Peer, Glendale, CA
Author Responds:
I agree with Peer that Communications should hold discussions on public-policy issues involving computing and information technology, though I do not think ACM members have any special expertise that can be brought to bear on the issue of coal-fired power plants.
Moshe Y. Vardi, Editor-in-Chief
Liability and Braces
The Letters pages “Let the Liable Pay” (Jan. 2016) included a letter under that title by Jonathan Handel on software liability followed by a letter by Jamie Hale under the subhead “Hold the Braces and Simplify Your Code” on ways to make code in languages that use braces more readable. (These languages seem to follow a design principle emphasizing ease of writing programs over ease of reading them, so one would think developers interested in creating readable code would simply avoid using such languages.)
Consider the software that flies commercial airliners, in which an error can lead to significant liability, as measured in billions of dollars, not to mention the deaths of hundreds of people. Producing and certifying software of the required level of correctness, reliability, and robustness is expensive, and airplane manufacturers seek ways to minimize that expense. For economic and safety reasons, both Airbus and Boeing use the same braces-free language for their software, and millions of people trust their lives to it. It follows then, that in a reasonable world, all software that should be correct, reliable, and robust would be implemented in such a language and to such standards. All safety-critical software, as in cars, trains, and other vehicles, and that operates medical devices, should be required to be certified to similar standards. Such software also runs the Internet and all financial and commercial sites; for privacy protection, all software on phones and mobile devices; and, since software correctness cannot be guaranteed if run on an incorrect foundation, all operating systems correct software would run on. That this is usually not the case represents a serious condemnation of the software-engineering profession.
As for Hale’s recommendation to write short blocks of code, while that is good advice, the labeling of terminator markers, which he dismissed as unnecessary, is still a good idea. The language used in commercial flight software requires terminating if statements with end if;, records with end record;, case statements with end case;, and so on. Many constructs can be labeled with a name that then appears in the terminator— end loop Name;. This is because there is evidence block terminators are a common source of error, and such labeling reduces such errors, even for short blocks. Short terminators (such as a brace) are a greater source of error than long terminators (such as end), which is why braces are avoided. Safety and readability are designed into the language rather than as an afterthought.
The economic pressures to expand liability to more software would thus be expected to lead to a reduction in the use of languages with braces, along with an associated increase in readability.
Jeffrey R. Carter, Mesa, AZ
A Log Graph Too Far?
I really enjoyed George V. Neville-Neil’s article “Time Is an Illusion Lunchtime Doubly So.” (Jan. 2016) and am a big fan of his Kode Vicious columns as well. However, I could not fathom the intriguing figure (see it here) in the article, labeled simply “PTP log graph,” nor could I find any reference to it in the text that might shed light on what property of the Precision Time Protocol it is supposed to illustrate. Not being an electrical engineer myself, I thought it might be something obvious to someone in the field, yet a friend with a Ph.D. in electrical engineering was equally flummoxed. It was such an interesting chart I am keen to understand what it means—if I can. Prof. Neville-Neil, can you enlighten me?
John Beresniewicz, Half Moon Bay, CA
Author Responds:
The PTP Log Graph in the figure showed the offset of a system clock that is not regulated by an outside time source (such as NTP and PTP). Without an outside time source, the clock wanders away from where we would expect it to be if the system’s crystal oscillator was more stable, which it is not.
George V. Neville-Neil, Brooklyn, NY
Join the Discussion (0)
Become a Member or Sign In to Post a Comment