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 termi-
IAPPRECIATED PHILLIP G. Armour’s use of coupled pendulums as an analogy for software project management in his The Busi- ness of Software column “The
Chaos Machine” (Jan. 2016) but would
like to set the record straight on a few
technical points. Chaos is already be-
ing 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 vari-
ables. 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 leav-
ing it unattended, is not a good idea. A
good case in point for how an unattend-
ed 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 Communica-
tions addressing such weighty issues
as “lethal autonomous weapon sys-
tems” through Moshe Y. Vardi’s Edi-
tor’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 profes-
sionals should indeed be paying at-
tention 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

Reference

1. Schwartz, T. Addicted to distraction. New York Times (Nov. 28, 2015); http://www.nytimes.com/2015/11/29/ opinion/sunday/ addicted-to-distraction.html?_r=0

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.