Skip to content
Skip to main content

About this free course

Download this course

Share this free course

An introduction to software development
An introduction to software development

Start this free course now. Just create an account and sign in. Enrol and complete the course for a free statement of participation or digital badge if available.

8.1.5 Keshav’s second pass

Keshav says that the second pass should take about an hour. The goal of the second pass is to be able to summarise the ‘main thrust of the paper, with supporting evidence, to someone else’, i.e., to be able to reconstruct the reasoning that the paper uses in its contribution to knowledge or practice.

Keshav advises the reader to take greater care on the second pass, but to ignore highly technical details such as proofs, implementations or detailed justification of any argument – indeed, anything that will extend outside of the one-hour window you have to read the paper a second time.

Keshav proposes indicators of a paper’s quality. For him, figures, diagrams and other illustrations should have been carefully set out so as to give the reader all the information he or she needs.

Finally, Keshav suggests marking interesting references, so that the portion of the literature upon which the arguments of the paper rest can be read (see Figure 3).

Described image
Figure 3 The references list at the end of Keshav’s paper (Keshav, 2007)

Activity 19

Do a second pass through Keshav’s paper. Try to explain your understanding of the paper to someone else.

Discussion

In trying to explain Keshav’s work, we came up with the workflow in Figure 4 (here’s a scalable PDF download of this image [Tip: hold Ctrl and click a link to open it in a new tab. (Hide tip)] ).

Described image
Figure 4 Our diagrammatic representation of Keshav’s workflow

This paper’s workflow depends upon various conventions being followed by an academic article and which are to all intents and purposes followed in the sciences (including software development as an academic discipline). In other areas of software development such conventions may not necessarily hold – for example, commercial (or white) papers may deviate.

The conventions assumed of a written academic item are that it will have:

  • An abstract, which is a brief summary of the item – whether it be a research article, thesis, review, conference proceeding or any in-depth analysis of a particular subject or discipline. The abstract is used to help the reader quickly ascertain the item’s purpose.

  • A number of sections, beginning with an introduction and ending with conclusions and/or a discussion.

  • A bibliography, essentially a list of literature and other material, such as web pages (and even personal communications between researchers) to which the reader of the article can refer to check the arguments and evidence that others have presented and which form the paper’s basis.