Make Abstracts Communicate Results

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

Ivar Jacobson and Ed Seidewitz, Verbier, Switzerland

Back to Top