Sign In

Communications of the ACM

Letters to the Editor

Make Abstracts Communicate Results


View as: Print Mobile App ACM Digital Library Full Text (PDF) In the Digital Edition Share: Send by email Share on reddit Share on StumbleUpon Share on Hacker News Share on Tweeter Share on Facebook
Letters to the Editor

Credit: iStockPhoto.com

Hermann Maurer's viewpoint "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, and ACM-sponsored conference proceedings and journals in particular, include 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 "Conclusions and Future Work," to discover whether the results are even interesting. 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 regard, with meaningful titles conveying 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 dispassionate 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 papers and articles to follow suit, making sure to include abstracts that summarize results and key concepts. I likewise call on editors, program chairs, and reviewers 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

Back to Top

Skip Grand Visions for Software Development

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 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 isdynamic, growing, in need of improvement, but not anywhere near the point of making grand pronouncements like SEMAT.

Dean Wampler, Chicago, IL

Back to Top

Authors' Response:

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 bettera hope shared by Google, which even held a three-day workshop on Essence.

Ivar Jacobson and Ed Seidewitz, Verbier, Switzerland

Back to Top

Footnotes

Communications welcomes your opinion. To submit a Letter to the Editor, please limit yourself to 500 words or less, and send to letters@cacm.acm.org.


©2015 ACM  0001-0782/15/03

Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and full citation on the first page. Copyright for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or fee. Request permission to publish from permissions@acm.org or fax (212) 869-0481.

The Digital Library is published by the Association for Computing Machinery. Copyright © 2015 ACM, Inc.


 

No entries found

Sign In for Full Access
» Forgot Password? » Create an ACM Web Account
Article Contents:
  • Introduction
  • Skip Grand Visions for Software Development
  • Authors' Response:
  • Footnotes
  • ACM Resources