Recovering the emergent logic in a software design exercise

This paper develops a deeper understanding of professional software design by examining the emergent logic of a software design exercise. Decision-making is evident as a ‘product’ of activity, including coordinated attention to primarily two artefacts, the brief and the whiteboard. Thus, we pay attention to the ‘situatedness’ of decision-making, which is not one person’s accomplishment, but is interactively carried out through treating what is known to the participants such as requirements written in the brief as ‘documentary’ of what is to be understood. The paper examines how each pair resolved the requirements uncertainties, by treating different ‘users’ differently. Our examination reveals how different approaches to the design exercise were actually organised to shed new light on software design practices.

[1]  Bonnie A. Nardi,et al.  A Small Matter of Programming: Perspectives on End User Computing , 1993 .

[2]  Hans van Vliet,et al.  What makes software design effective , 2010 .

[3]  André van der Hoek,et al.  Ideas, subjects, and cycles as lenses for understanding the software design process , 2010 .

[4]  Eric Livingston,et al.  Ethnographies of Reason , 2008 .

[5]  Rita Assoreira Almendra,et al.  Accessing decision-making in software design , 2010 .

[6]  Harold Garfinkel,et al.  Ethnomethodological Studies of Work , 1986 .

[7]  John Rooksby,et al.  Collaboration in Formative Design: Working Together at a Whiteboard , 2012, IEEE Software.

[8]  Barry W. Boehm,et al.  A spiral model of software development and enhancement , 1986, Computer.

[9]  Joseph A. Goguen,et al.  Requirements engineering: social and technical issues , 1994 .

[10]  Eric Livingston,et al.  The Ethnomethodological Foundations of Mathematics , 1986 .

[11]  H. Garfinkel Studies in Ethnomethodology , 1968 .

[12]  Bob Anderson,et al.  The user as a scenic feature of the design space , 1994 .

[13]  Adrian Mackenzie,et al.  From Cards to Code: How Extreme Programming Re-Embodies Programming as a Collective Practice , 2004, Computer Supported Cooperative Work (CSCW).

[14]  Louis L. Bucciarelli,et al.  An ethnographic perspective on engineering design , 1988 .

[15]  Pablo Romero,et al.  "Talking the talk": Is intermediate-level conversation the key to the pair programming success story? , 2007, Agile 2007 (AGILE 2007).

[16]  Laurie A. Williams,et al.  Strengthening the Case for Pair Programming , 2000, IEEE Softw..

[17]  Kostas Zografos,et al.  Requirements elicitation for the design of venue operations for the Athens 2004 Olympic games , 2003, Proceedings. 11th IEEE International Requirements Engineering Conference, 2003..

[18]  John Rooksby,et al.  Knowledge and Reasoning about Code in a Large Code Base , 2006 .

[19]  Christian Heath,et al.  Technology in Action: Team work: collaboration and control in London Underground line control rooms , 2000 .

[20]  Kent L. Beck,et al.  Extreme programming explained - embrace change , 1990 .

[21]  Duncan Sanderson,et al.  Coordinating joint design work: the role of communication and artefacts , 1998 .

[22]  Helen Sharp,et al.  An Ethnographic Study of XP Practice , 2004, Empirical Software Engineering.

[23]  John T. Nosek,et al.  The case for collaborative programming , 1998, CACM.

[24]  Herbert A. Simon,et al.  The Structure of Ill Structured Problems , 1973, Artif. Intell..

[25]  Scott R. Klemmer,et al.  Pair Programming: When and Why it Works , 2005, PPIG.

[26]  Dan Shapiro,et al.  From ethnographic record to system design , 1992, Computer Supported Cooperative Work (CSCW).

[27]  S. Woolgar,et al.  Representation in Scientific Practice , 1990 .