time or patience for grand visions of
“how we should do our jobs,” as in Software Engineering Method and Theory,
or SEMAT, the related Essence kernel
and language, or whatever the current
fashion is called.
I have worked with many teams in
successful and less-successful organizations over the years. The winners
are pragmatists, carefully picking and
choosing the practices that satisfy their
needs. They are rooted in computer science, knowing and using essential data
structures, algorithms, and the rest.
They are minimalists, minimizing the
code they write while constantly proving it through logic and performance
tests. They want to get work done,
knowing what “done” means.
I know that many people are embarrassed we are not a mature engineering discipline like other, older fields.
I gave up on this idea long ago, recognizing software development for what
it is—dynamic, growing, in need of
improvement, but not anywhere near
the point of making grand pronouncements like SEMAT.
Dean Wampler, Chicago, IL
Essence is exactly about practitioners
picking and choosing their own practices
in order to “get the work done.” Despite
progress in software engineering, we
still seem to reinvent the wheel a lot.
Pragmatists often take a long road of hard
knocks before finding practices that work for
them. Rather than a “methodology to end
all methodologies,” we propose a common
ground to disseminate the community
experience needed by practitioners, not from
“embarrassment” with traditional software
engineering but in hope for better—a hope
shared by Google, which even held a three-day workshop on Essence.
Ivar Jacobson and Ed Seidewitz,
Communications welcomes your opinion. To submit a
Letter to the Editor, please limit yourself to 500 words or
less, and send to email@example.com.
© 2015 ACM 0001-0782/15/03 $15.00
HERMANN MAURER’S VIEW- POINT “Does the Internet Make Us Stupid?” (Jan. 2015) made an important point in its first two sentences, that
no one reads full papers anymore. Taking it to heart, ACM should make its
publications communicate more effectively by insisting abstracts include
a summary of results and key concepts,
communicating important information even when readers skip or skim the
rest. Maurer also said Internet technology is to blame for superficial reading
habits, but I recall when as a graduate
student I stopped reading full articles
in AAAS Science, focusing on just the abstracts to decide whether or not to continue. That was the late 1970s, well before the rise of the Internet, so I cannot
blame the Internet. I could, however,
rely on abstracts in Science because they
were so good at summarizing results.
As my focus turned to engineering,
I stopped reading Science and concentrated on IEEE and ACM publications.
However, many engineering papers,
Skip Grand Visions for
and ACM-sponsored conference pro-
ceedings and journals in particular, in-
clude notably unenlightening abstracts.
It is as if the authors intend to hide their
results to force the reader to read the
entire paper or at least skip to the final
subhead, usually something like “Con-
clusions and Future Work,” to discover
whether the results are even interest-
ing. The goal, it appears, is not so much
to transmit information but force the
reader to appreciate the author’s pages
of laboriously composed prose.
Newspaper editors and reporters
structure their work better in this re-
gard, with meaningful titles convey-
ing the core concept, followed by a
one-paragraph introductory summary,
or lede, followed by the full narrative.
This is perhaps due to professional
editorial oversight, whereby a dispas-
sionate editor is able to demand an
author concede the major points up
front, knowing the reader is unlikely to
endure the whole article.
I thus call on authors of scientific pa-
pers and articles to follow suit, making
sure to include abstracts that summarize
results and key concepts. I likewise call
on editors, program chairs, and review-
ers to enforce this requirement. Good
abstracts improve the communication
bandwidth of the printed word. It is good
engineering and only fair to the reader.
Steve Trimberger, Incline Village, NV
Software development (or engineering
if you prefer a more highbrow term)
is still a nascent field, as discussed by
Ivar Jacobson and Ed Seidewitz in their
article “A New Software Engineering”
(Dec. 2014). The rapid evolution and
progress developers have made over
my 25 years in the field remains one of
its key attractions. I am never bored.
And there is no sign this rapid pace will
slow anytime soon. The idea of “a new
software engineering” simply does
not square with the state of the art as
practiced in software organizations all
around us. Teams within Google, Microsoft, Amazon, Twitter, and countless other organizations have little
Make Abstracts Communicate Results
Sketch-Thru Plan: A
Multimodal Interface for
Command and Control
a House Without
Use of Formal Methods
at Amazon Web Services
in Medical Devices
Go Static or Go Home
Plus the latest news about
designing medical molecules,
current side-channel attacks, and
the growth of dynamic pricing.