Classical Papers in Computer Science and Software Engineering: A Reading Group

Reading technical papers typically is a lone activity. Does it have to be? To find out, we ran a reading group. The group members read a famous and/or seminal paper from computer science and software engineering and then met to discuss it.¹

The idea for our reading group stem from a university course in a humanities faculty that tasks students to read classical papers in philosophy as a term assignment, and then present and discuss those papers. Writers’ Workshops at pattern conferences and the “Literaturclub” on Swiss TV featuring fiction books also provided inspiration.

I’ll review our paper selection criteria, the discussed papers and organizational matters in this post and end with lessons learned.

Paper Selection Criteria

Picking study material often is somewhat subjective. To objectify, we identified candidate papers from three perspectives:

• Curiosity: Personal interest about a topic area and the roots of concepts such as information hiding and separation of concerns was a main selection driver.
• Relevance: Our focus areas in professional services, teaching, research and development suggested articles with high impact on practice and/or mentioned often in publications and online resources.
• Reputation: Paper credentials, content and writing style, and author recognition also were considered. For instance, Turing Award lectures and laudations often comment on important and influential papers.

We tried to be diverse regarding topic area, paper age and contribution types — the nature of the activities across the software development lifecycle from requirements to design, implementation, test and then on to operations, evolution and maintenance is diverse. Problems are solved differently along the way. Hence, supporting practices, methods and tools come in many forms and facets.²

The Reading List: Brooks, Conway, Dijkstra, Parnas + 3

We created a long list with 20+ entries first, reduced to a short list next. Ordered by appearance in reading group sessions, this short list is:

1. “No Silver Bullet Essence and Accidents of Software Engineering” by Fred(erick) P. Brooks, IEEE Computer, April 1987. The identification and discussion of two types of challenges and complexity in software engineering, essential and accidental, is one of several key contributions of this paper. Note that a minor update to the paper (table/figure) and a “ten years later” reflection by the author appear in the anniversary edition of the book “The Mythical Man Month”.
2. “Time, Clocks, and the Ordering of Events in a Distributed System” by Leslie B. Lamport, Communications of the ACM, July 1978. The state machine concepts in this frequently cited paper combined with a consensus algorithm yield PAXOS, which has many production uses. The author comments on this paper and its popularity on his website.
3. “How do Committees Invent?” by Melvin E. Conway, published in Datamation in 1968. This paper is often mentioned in presentations about Domain-Driven Design (DDD) and microservices. The author gives some historical context on the referenced web page. A diagram zoom-in as seen in popular models for architecture diagramming nowadays already appears in this paper!
4. “Structured Design” by Wayne P. Stevens, Glenford J. Myers, and Larry L. Constantine, IBM Systems Journal, May 1974. This paper presents one member of the “Structured NN” methods popular before object-orientation became big in the 1990s. It investigates types of coupling and cohesiveness and proposes a structure chart notation complementary to flowcharts. The paper was followed by a book of the same name in 1975.
5. Barry W. Boehm, “A Spiral Model of Software Development and Enhancement”. We read the IEEE Computer version from May 1988; a paper with the same title was published in ACM SIGSOFT Software Engineering Notes in August 1986 (open access). The paper suggests a risk orientation of engineering processes. It already uses many terms and concepts that are mainstream now, for example unit test and acceptance test.
6. Edsger W. Dijkstra, “On the role of scientific thought”, the essay that coined the term separation of concerns, August 1974. Click on EWD447 at the top right to download a PDF scan. Scientific thought refers to “a way of thinking” here, which is also applicable in practice. EWD 340 is “The Humble Programmer”, the author’s Turing Award Lecture from 1972.
7. David L. Parnas, “On the Criteria To Be Used in Decomposing Systems into Modules”, Communications of the ACM, December 1972 (open access, PDF). A definite classic, credited as the source of the term information hiding and arguably one of the first papers to talk about design decisions (and hiding decision outcomes behind interfaces). This book, collects and comments all papers by Parnas.

While this list compounded our essential reading, is does not claim to be complete or representative! It merely fit our interests at the time. The long list was a lot more diverse than this short list suggests, for instance in terms of paper age and topic areas.

Reading Group Organization

Let’s look at setup and execution of reading group sesssions now, including follow up.

Reading period. We took turns in selecting papers from the long list and the short list. We decided which paper to read two weeks before the next discussion session and then went separate ways.

Usually, we only read the chosen paper and ignore reactions to it or follow-up work before the discussion session (in order not to get influenced or derailed). In a few cases, group members looked up supplemental resources such as explanatory videos or blog posts.

Session execution. A paper discussion session lasted for 60 to 90 minutes, depending on length of the selected paper and the participant’s desire to go deep in certain places (e.g., discuss paper reception). We met face-to-face most of the time. Two sessions took place online; one was hybrid.

A moderator was chosen first, either somebody volunteered or somebody “was volunteered” in a round-robin manner 😉. The agreed upon setup was recapitulated and adjusted (in the first sessions). The discussion was then organized in three rounds: 1) opening, 2) main, 3) closing.

Round 1. Items discussed and questions answered in the opening round include:

• Why did we decide to read this paper? Why did the person that suggested the paper (“champion”) recommend it?
• When and where was the paper published?
• Is there anything that stands out, not only in the paper body but also in the metadata, the abstract and/or the acknowledgments?

Some historical context (for the young ones and the elder that do/do not remember) are reflected or looked up. Participants are allowed to speculate a bit about publishing process and tools used for typesetting and drawing (some papers on our shortlist predate Latex and even Tex).

The following impressions are exchanged and questions answered:

• When and where did you read? Online or in print? How long did it take you?
• What did you like? Do you (dis-)agree? Is the content still valid today? Any surprises?
• What do you want to discuss specifically in Round 2? Which paper parts are particularly interesting? Where did you ask yourself how other participants reacted to the messages sent?

Round 1 takes 10 to 15 minutes. Typically, the paper champion starts. Running gags (such as “for the folks out there in TV land”) can begin to form.

Round 2. This main round takes the bulk of the time (40 to 60 minutes). We comment and discuss page-by-page, in a rather flexible way with no particular order:³

• Content: Quotes we like. Agreement, different views and opinions, surprises; actuality. Things we do not understand (clarification needs).
• Presentation and content of examples given; software quality attributes mentioned, as well as programming languages, tools, other concepts featured in the examples.
• Writing style, e.g., structure, wording, diagrams, metaphors; methodical flaws or signs of ethical concerns (yes, even the big names did not get everything right all the time).

A somewhat provocative question that may be asked in this round is: how would group participants reacted if they had been assigned as peer reviewers of the paper back in the day?

Round 3. In the closing round (10 to 15 minutes), we discuss:

• Take aways from paper itself and learnings from the paper discussion.
• Change of perception caused by discussion and other reader reports.
• What to do with the take aways and the learnings.

At the end of each session, we reflect a bit and thank each other for time spent. Or simply run off to the next meeting. 😉

Follow up. We tried to follow up to keep the gained insights alive and possibly extend them. Taking and writing about the paper concepts helps. For example:

• I tried to separate concerns in the sections of the post.
• I decided to report essential rather than accidental challenges in reading group design in this post.
• When you read this, the Web browser renders HTML; the information that this HTML was produced from a Markdown file via Jekyll and then transported via HTTP is hidden.

Schedule and workload permitting, we looked up additional publications and online resources from the author, as well as articles, papers and blog posts referring to it (agreement, critique).

Lessons Learned

Reading and discussing the papers was very enjoyable and educational overall. We enjoyed the face-to-face sessions more than the online and hybrid ones.

We encountered some tough moments while reading and while discussing because of unfamiliar writing styles, type and amount of material to be digested and time constraints. In a few cases, we skipped pages or (sub-)sections. In other cases, we decided for a short clarification breaks.

Some disappointments were caused by wrong expectations about the papers, caused by their reception elsewhere. This is quite ok and has happened to other readers too. In other cases, we discovered precious insights (and jokes) somewhat unexpectedly. For example, the reason we selected “On the role of scientific thought” was that this paper is seen as the first appearance of the term “separation of concerns”, but its scope and messages actually are much broader.⁴

The public perception and positioning of the paper may differ from original scope or paper and author intent. Some examples or design priorities might be dated or even obsolete by now as hardware capacities, programming languages and their ecosystems have evolved quite a bit since the paper was written.

Some moderation is needed, for time keeping in particular. The moderator (and everybody else) should monitor how the discussion is going and make sure that all session participants are engaged and involved.⁵ It is perfectly fine to disagree here and there. Humor and storytelling, for instance about project situations in which the paper concepts helped (or caused friction), serve well as re-energizers.

The desire to dive in deeper kept coming back. During each session, we had to make some tough decisions to stay in time, as we often would have wanted to discuss certain parts longer, down to single sentences or words — a depth vs. breadth tradeoff! When time got tight, participants sometimes asked whether digressing (and which amount of) is ok. The decision making should not take longer than the actual digression, which brings us back to the importance of a friendly but also strong moderator.

You might want to look for secondary literature after the session, for instance other works by the author. Not looking at secondary literature before the discussion sessions helps not to be influenced positively or negatively due to biases.

Wrap Up

You learn a lot when reading together — about content, about reading habits, about reader preferences and expectations. We often agreed on our impressions and findings, but alo had many “aha” moments when others commented on certain paper parts. Serendipity in action! Our personal toolboxes (in the wide sense of the word) definitely grew.

We encourage you to read some of the papers we read (or create your own list), either for yourself or in a reading group like ours. There is a lot to learn from the past… check out Papers We Love, maybe there is an active group near you!

Which paper would you like to read, or recommend? Let me know.

– Olaf

Notes