Eventyr

Attuning (SoP)

Turner, G., A. Weakley, et al. (2005). Attuning: A Social and Technical Study of Artist-Programmer Collaborations. 17th Meeting of the Psychology of Programming Interest Group, University of Sussex, Brighton, UK. [PDF]

This paper discusses findings from studies of the role of programmers in art-technology collaborations (both social and technical). It considers the role of programming in the digital art domain. The authors note that it is unclear how software development methodologies vary from methodologies for generating interactive art (excluding HCI techniques for evaluating interactive art).

Collaboration is within two types of community:
COP (Communities of Practice) - People from similar backgrounds
COI (communities of Interests) - Where people from different backgrounds contribute to the same project.

The latter come with different languages and knowledge systems which makes building a shared understanding of the task a difficult and slow incremental process. Boundary objects allow for a shared reference within systems.

The collaboration was investigated using grounded-theory (and the approach is nicely summarised). The data was taken from semi-structured qualitative interviews.

This produced a theory that ``The programmers role is to attune the computer to the artist, through either `Intimate Iteration' [small iterations to system] or `Toy-Making' [program as `toy' for the artist to work with].''

The data showed that there are different types of collaboration between artists and programmers (programmer as assistant, full-partnership with artist control, and full partnership. (For further details on these groupings see Maeda and Burns 2004.)

They also noted that vague artistic description needed to be understood by the programmer as there is a dichotomy between analysis and synthesis.

In all cases studied, bottom up development was used to aid the attuning process, and in all but one an agile development methodology was applied.

An ethnographic Study of XP Practice (SoP)

Sharp, H. and H. Robinson (2004). "An ethnographic Study of XP Practice." Empirical Software Engineering 9: 353-375.

This paper discusses the findings from an ethnographic study of XP practice as applied in a small company working on web-based advertisements. Five characteristic themes within XP practice are identified and summarised in terms of XP culture.

The paper gives a clear summary of agile systems, with an introduction to XP, as well as a clear introduction to their ethnographic approach (see Sim 1999). The paper is motivated by a desire to ``gain insight into the culture and community of an agile method as part of a broader agenda of an examination of the culture and community of software engineering''

The following themes were noted and discussed in detail following the ethnographic analysis:

1: Shared Purpose, Understanding and Responsibility
This was achieved through:
a) The Planning Game: The planning game in this instance lasted almost three days in order for the group to fully understand and agree on the stories they would be working on and resolve any conflicts.
b) Stand-Up Meetings: Lasting a maximum of 15 minutes, each morning the developers would meet and share experiences from the day before, and pick cards and partners for the day.
c) Pair programming: Pairing rotated every day and everyone was involved. ``...we would argue that pair-programming is as much about continuing that face-to-face communication as it is about writing code.'' The importance of peripheral awareness is also mentioned. See Cockburn 2000 for a discussion of oral tradition.
d) Documentation: Cards were used in many different ways throughout the process but were discarded as soon as no longer needed.
e) Metaphor: A group metaphor is maintained to promote group understanding, and was noted as ``a fundamental facilitator for maintaining the shared vision.''

2: Coding and Quality of Code Matters (Strong concern about quality of code and refactoring)

3: Sustainability (and team concern about the quality of life)

4: Rhythm (pervasive rhythm/routine both daily and in three-week cycles)

5: Fluidity (fluid boundaries as an organisational element, especially in office layout)

The discussion defends the ethnographic approach against the 'so what' argument (which is worth noting for the future) and continues by discussing the limitations of the approach.

The paper is concluded and summarised with the claim that there are four main characteristics of xp culture:
1. Both individuals and the team are respected
2. Both individuals and the team take responsibility
3. Both individuals and the team actively encourage the preservation of the quality of working life
4. Both individuals and the team have faith, affirmation and validation in their own abilities and that of the team to complete the goals at hand.

Mental Imagery in Program Design and Visual Programming (SoP)

Petre, M. and A. F. Blackwell (1999). "Mental Imagery in Program Design and Visual Programming." International Journal of Human-Computer Studies 51(1): 7-30.

This paper reports two studies justifying the use of diagrams and VPLs in software design, which aimed to elicit statements about mental imagery from expert programmers and thereby refine the claim that ''expert programmers use mental imagery in order to specify, predict and simulate program behaviour.''

``Despite considerable individual variation, multiple participants concurred in describing imagery that was stoppably dynamic, allowed local attention, had adjustable granularity of abstraction, was provisional and variable, had many dimensions and included information in multiple sensory modes - multiple images in addition to accessible labels.''

Study one involved detailed interviews with 10 expert programmers. Experts (of various languages) were asked to design (not implement) one of four problems as code. They were questioned during and after their task about their mental images.

``The first study used a combination of observation and interview techniques which had, in previous studies, proven effective at eliciting rich qualitative data of this ilk. It adopted a loose protocol of questions which appeared in pilot interviews to elicit descriptions that both surprised and satisfied those questioned. The ability to engender surprise and satisfaction have, in previous studies, been effective criteria for elicitation questions. When a subject is surprised during an interview, it suggests a divergence from routine rehearsed response, whether in the form of a new expression, a new perspective, or a re-consideration''

Study two was a questionnaire study of 200 users of a commercial VPL. These questionnaires were coded with specific interest paid to statements about mental representations. The majority of participants did not provide detailed information about mental representations.

The paper lists the types of imagery described in the programming tasks (and in the questionnaires, although this data was less interesting). This will be discussed in more depth seperately, but for the moment the list is as follows:

Imagery reports during programming tasks:
A) Dancing symbols
B) Mental description/discussion
C) Auditory imagery
D) Visual imagery
E) Machines in their minds
   i. Abstract machines
   ii. Pictures of implementations
   iii. Mechanical analogy
F) Surfaces
G) Landscapes
H) Presences

Common Elements in Concurrent Reports:
1. Stoppably dynamic
2. Focal attention
3. Adjustable granularity of abstraction
4. Provisional, variable
5. Many dimensions
6. Multiplicity
7. `The name business'

It is also interesting to note that the imagery found related to solution construction and not debugging as some of the experts made comments which suggested that a different imagery would be used for this process.

Does Metaphor Increase Visual Language Usability? (SoP)

Blackwell, A. F. and T. R. G. Green (1999). Does Metaphor Increase Visual Language Usability? 1999 IEEE Symposium on Visual Languages (VL'99).

This paper considers the claim that visual languages support learning through a visual metaphor of the system that increases usability. Experimental results showed that there were no significant usability benefits when using metaphors as opposed to non-metaphorical interfaces.

Metaphor or Analogy (SoP)

Blackwell, A. F. (1996). Metaphor or Analogy: How Should We See Programming Abstractions? 8th Annual Workshop of the Psychology of Programming Interest Group.

This paper looks at the roles of analogy and metaphor in the psychology of programming (as related to programming abstractions), and claims there is good reason for distinguishing between analogy and metaphor when discussing systems metaphors. The paper suggests research on this topic for analysing visual programming environments.

How to Be My Student (SoP)

How to Be My Student

The paper summarises several important points that any student should remember about the supervisor/student relationship.

Particularly relevant for me to remember are the following:

* Ensure that meetings are regular and scheduled well in advance
* NEVER cancel if behind schedule
* If possibly provide reading material to supervisors a day in advance
* Email summary of main points covered after the meeting
* Make sure to look at courses on transferable skills and research methodologies
* Do not try to hide any problems from supervisors

How To Write An Informatics Paper (SoP)

How To Write An Informatics Paper

Hopefully I should be fairly well placed for writing papers, having edited so many over the last few years. We shall see.

This paper summarises good and bad form in Informatics Papers and most of the points felt like issues I had covered while learning to write philosophy papers, so I do not feel a need to summarise them here.

The structure given for a standard informatics paper is:
Title
Abstract
Introduction
Literature Survey*
Background*
Theory*
Specification*
Implementation*
Evaluation
Related Work*
Further Work*
Conclusion
Appendices*

The Researchers Bible (SoP)

The Researchers Bible

As a summary document it seems like it would be very useful to any researcher starting out, although it is understandably strongly targeted towards AI researchers. I found there were many points that I either found familiar or had worked through already (especially 3.1 and 4.1), however, so the following are the major points that I thought were worth noting in my case:
* After looking it up, at Sussex the definition for award of a DPhil is that, 'for the award of the Doctor of Philosophy, that the thesis makes a substantial original contribution to knowledge or understanding.'
* 3.10 (Methodology Does Not Make A Thesis) / 3.11 (The Discovery Route is Not Justification): These are both points that I need to consider and address this term and I feel that my essay for the Research Methods Course should help me with this.
* 4.4 (Early Morning - Cold Start): I should make sure I set a formal work schedule to give fair time to both my research and my work, preferably making sure that the first task of the day is simple and not something I will find other tasks to avoid.
* 7 (Writing Papers): This section suggested I should make lots of notes and make writing a part of my life. Hopefully I will achieve this with this site...
* 9 (Guide to Reading): I need to re-evaluate my reading and try to keep up-to-date with it. It may be worthwhile for me to make a list of relevant Conferences and Journals here at some point as well as re-subscribing to an abstracts database.