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).
Do a second pass through Keshav’s paper. Try to explain your understanding of the paper to someone else.
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).
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.
OpenLearn - An introduction to software development Except for third party materials and otherwise, this content is made available under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 Licence, full copyright detail can be found in the acknowledgements section. Please see full copyright statement for details.