A Note on Communication

I've been working full-time with experimental biologists for about seven months now, and the experience has reminded me of just how bad most software engineering researchers are at writing abstracts. An abstract isn't supposed to be like a movie trailer, designed to lure me into paying $13 to watch the whole thing; it's supposed to summarize the actual findings so that (a) I know a couple of things I didn't before, and (b) I can make an informed judgment about whether it's worth reading the whole thing.

For example, the abstract of one bio paper I looked at recently was, "We show that wild-type PfMDR1 transports diverse pharmacons, including lumefantrine, mefloquine, dihydroartemisinin, piperaquine, amodiaquine, methylene blue, and chloroquine (but not the antiviral drug amantadine). Field-derived mutant isoforms of PfMDR1 differ from the wild-type protein, and each other, in their capacities to transport these drugs, indicating that PfMDR1-induced changes in the distribution of drugs between the parasite's digestive vacuole (DV) and the cytosol are a key driver of both antimalarial resistance and the variability between multidrug resistance phenotypes."

Compare that to the abstracts of the two papers cited below. I enjoyed the papers themselves—they both contain interesting, actionable results—but but their abstracts describe what they're going to say rather than actually saying it:

• "We quantify the prevalence of 0.y.z releases…" Great: give me a couple of key numbers here in the abstract, please.
• "…we explore how long packages remain in the initial development stage…" And found that…?
• "…we compare the update frequency of 0.y.z and ≥1.0.0 package releases…" And found that…?
• "…we assess whether semantic versioning is respected for dependencies towards them…" Is it?

The abstract of the first paper does include some specific findings, though it saves them for the end when they should be the opening. The abstract for the second paper doesn't even do this: a sentence like, "We explore to what extent ecosystem-specific characteristics or policies influence the degree of compliance." could and should be replaced with a line or two telling me what was found.

Another thing I've noticed about software engineering papers' abstracts is that they assume much less background knowledge than the abstracts of papers in other domains. Again, the two papers below are better than many, but the opening two sentences of each of their abstracts say things that every plausible reader will already know.

I don't know why software engineering abstracts are written this way. What I do know is that researchers and practitioners alike are drowning in noise these days; everyone has to decide in the first fifty words whether the next hundred are worth reading because in the time it takes to read those fifty another five thousand have piled up. A paper isn't like a joke: it won't be spoiled if you lead with the punchline. Instead, I think people will be more likely to read it if they know up front what you're going to say.