# How (Not) To Write a Software Engineering Abstract

arXiv: https://arxiv.org/abs/2506.21634 · HTML: https://mlsanity.com/paper/2506.21634/

## Key facts

- Cited by 1 papers in the map (data through 14 Oct 2026).
- First posted on arXiv 25 Jun 2025.

## Built on by (most cited first, 1 of 1)

- [Specifying and Maintaining Agentic Workflows: An Empirical Study of GitHub Agentic Workflows](https://mlsanity.com/paper/2609.27263/) (2026)

## Abstract (arXiv)

Background: Abstracts are a particularly valuable element in a software engineering research article. However, not all abstracts are as informative as they could be. Objective: Characterize the structure of abstracts in high-quality software engineering venues. Observe and quantify deficiencies. Suggest guidelines for writing informative abstracts. Methods: Use qualitative open coding to derive concepts that explain relevant properties of abstracts. Identify the archetypical structure of abstracts. Use quantitative content analysis to objectively characterize abstract structure of a sample of 362 abstracts from five presumably high-quality venues. Use exploratory data analysis to find recurring issues in abstracts. Compare the archetypical structure to actual structures. Infer guidelines for producing informative abstracts. Results: Only 29% of the sampled abstracts are complete, i.e., provide background, objective, method, result, and conclusion information. For structured abstracts, the ratio is twice as big. Only 4% of the abstracts are proper, i.e., they also have good readability (Flesch-Kincaid score) and have no informativeness gaps, understandability gaps, nor highly ambiguous sentences. Conclusions: (1) Even in top venues, a large majority of abstracts are far from ideal. (2) Structured abstracts tend to be better than unstructured ones. (3) Artifact-centric works need a different structured format. (4) The community should start requiring conclusions that generalize, which currently are often missing in abstracts.