On Paper Titles (Bad Ideas, Rejected Ideas, and Final Titles)

(This is an old article from 2015, migrated over from https://www.cs.cmu.edu/~ckaestne/ontitles/)

Our paper “The Love/Hate Relationship with The C Preprocessor: An Interview Study” has just been accepted for ECOOP 2015 and that was one of the papers for which we discussed possible titles in quite some length. I would like to use this opportunity to reflect a little about our process of selecting titles and would like to share some rejected title ideas below…

I find selecting good paper titles quite difficult. A good title is short and easy to remember and says something about the work and preferably even something about the results. A title is the first thing a potential reader encounters and is the first and sometimes only criteria to decide whether to read or review the paper or attend the talk. A good title probably has quite some impact on whether the work is read and remembered.

I have a number of papers for which I regret the title. Our OOPSLA’11 paper “Variability-Aware Parsing in the Presence of Lexical Macros and Conditional Compilation” is a good example. Its title is technically precise but clunky. Variability-aware parsing is our own term and I don’t expect others have an intuitive idea of what it entails. A year later, an almost identical approach was published as “SuperC: Parsing all of C by taming the preprocessor” (there are lots of technical differences, but conceptually both papers are very similar and make ideas of splitting and joining parsers going back to the early 1980s and 1990s work at a large scale). The SuperC title is shorter and much more intuitive. It describes the goal from the user’s perspective (parsing all of C) instead of the technical issues that make parsing unpreprocessed C code hard (lexical macros and conditional compilation). Although it’s true that you could use the technique also for other languages that use lexical macros and conditional compilation (and we have actually done so, for example, in the context of analyzing PHP), the main goal was and is to analyze C; I guess that people who can figure out that their problem is similar to parsing unpreprocessed C code can figure out that our tools might apply. The tool name SuperC in the title is definitively flashier than our concept of Variability-Aware Parsing. Although I like our tool name TypeChef, it doesn’t convey what it is about. Furthermore, since we used the name TypeChef in the title of an early workshop paper sketching a rough idea of the project, now some people tend to cite that now completely outdated paper rather than the actual later research that now allows us to parse, type check, and statically analyze unmodified and unpreprocessed C code at the scale of the Linux kernel.

For the ECOOP paper, we actually had a longer discussion about the title through several iterations over email and Skype. The paper is about an interview study with open source developers on how they perceive the C preprocessor. Essentially, we were wondering why people kept using the C preprocessor despite heavy criticism and why they would not adopt any of the alternatives that researchers have come up over the years (from syntactic preprocessors to languages with sophisticated metaprogramming facilities). Although problems are well known, even C# still contains lexical conditional compilation. Anyway, we needed a title describing that we studied the developers’ perception of the C preprocessor with interviews.

Our first placeholder title was “Why is the C preprocessor still breathing?”, but that felt a little aggressive and wasn’t saying much anyway. Going back to my email archive, here are a bunch of early suggestions:

• The C Preprocessor in Practice
• 50 Years is Long Enough
• Perceiving the Problems and Alternatives to the C Preprocessor
• Talking About the C preprocessor: Problems and Alternatives
• Interviewing Developers: Problems and Alternatives to the C Preprocessor
• Facts and Misconceptions about the C Preprocessor: A developer perspective — -
• A Developer perspective of the C preprocessor : Several problems but no alternatives
• Problems and Alternatives to the C Preprocessor: A developer perspective

Some of them indicate how we performed the study and they are more or less describing our research questions, but none cover any results. At this point, we started brainstorming a bit for titles. One patterns for titles that I like (that I noticed first explicitly with Emerson’s paper “Cowboys, ankle sprains, and keepers of quality: how is video game development different from software development?”) is to use bits of results or quotes in the title. This doesn’t convey much meaning upfront, but makes the paper easy to remember when you have seen the results and see how they are reflected in the title. Here are a list of suggestions:

• Talking to C Preprocessor Experts: Problems, Discipline and No Alternatives
• The Love and Hate Relationship with the C Preprocessor: An Interview Study
• The Necessary Evil: Interviewing C Preprocessor Experts
• Talking about the C Preprocessor: Practices, Guidelines, and Enforcement
• Talking about the C Preprocessor: Errorprone but needed
• The Love/Hate Relationship with The C Preprocessor: An Interview Study
• Aware of Criticism, but Needed Nonetheless — Interviewing Developers about the C Preprocessor
• Error Prone but Needed Nonetheless — Interviewing Developers about Conditional Compilation
• Developers and the C Preprocessor: From Problem Awareness to Guidelines
• Talking about the C Preprocessor: Problems, Discipline, and Tools
• Error prone but needed: A Study on the Perception of the C Preprocessor
• “Don’t do it”: A Study on the Perception of Conditional Compilation (quote from the linux guideline that we quote on the first page)
• “Don’t do it”: An Interview Study on the C Preprocessor
• “Depends on the Project”: An Interview Study on the C Preprocessor
• “A real mess”: An Interview Study on the C Preprocessor
• Messy code, discipline, and guidelines: An Interview Study on the C Preprocessor
• “A necessary evil”: An Interview Study on the C Preprocessor
• “A necessary evil, much like goto”: An Interview Study on the C Preprocessor
• Bad ideas, messy code, and discipline: An Interview Study on the C Preprocessor
• Bad ideas, messy code, and balanced parentheses: An Interview Study on the C Preprocessor
• “Don’t Do It”, otherwise “Cross Your Fingers”: An Interview Study on the C Preprocessor
• #ifdef PREPROCESSOR “Cross Your Fingers” #else “No Alternatives” #endif: An Interview Study on the C Preprocessor

Together the titles actually already give a quite nice picture of the paper’s main results. As usual, the list develops from more to less serious suggestions, although the later ones often provide input for new ideas. After collecting many different ideas, we went through a number of additional refinements and then a voting process, resulting in a showdown between variations of

• The Love and Hate Relationship with the C Preprocessor: An Interview Study
• The Necessary Evil: Interviewing C Preprocessor Experts

The “Love/Hate relationship” we finally agreed on is actually one of the less descriptive titles, but still conveys a significant part of the story. It’s relatively short and easy to remember. Better to be remembered for the “Love/Hate” paper than for the “bad ideas” or “messy code” paper. :)

And while I’m already diving into old emails, here some alternatives to our paper “Understanding Understanding Source Code with Functional Magnetic Resonance Imaging”. I really like this title although (or because) almost everybody stumbles over the “Understanding Understanding” part in the beginning and we actually explain this in the beginning of the talk, but it also pretty exactly describes what the paper is about.

We went from

• “Measuring Program Comprehension with Functional Magnetic Resonance Imaging” (exact, somewhat bold, short enough, boring)
• “Understanding Program Comprehension from a Cognitive Neuroscience Perspective” (less precise, somewhat boring)
• “Looking into a Programmer’s Head — Understanding Program Comprehension”

to

• Measuring Brain Activity during Program Comprehension
• Cognitive Processes during Program Comprehension
• Understanding Understanding Source Code: An fMRI Study
• Program Comprehension requires Working Memory, Attention and Language Processing
• Left-Hemisphere Lateralization and other results from an fMRI study on Program Comprehension
• Program Comprehension with the Middle Frontal Gyrus (and some Inferior Gyri)
• Program Comprehension in the Brain
• We’re fed up with controlled experiments — Let’s look inside developers
• Why all your experiments were wasted time — The better way of measuring program comprehension
• Identifying genetic predestination for becoming an excellent programmer (or just Gattaca 2.0)
• Brains!
• Understand this!
• All this effort to design software metrics? Sure!
• Should I teach my child programming at the age of 3? (Maybe!)

And finally we met somewhere in the middle.