Eventyr

QCon - Friday

It being my birthday I only stayed at QCon for the morning.  This was a shame in a way as this day had some of the most interesting talks of the three days.  It also ended up being one of my busiest as a student helper (although I did not get the chance to use the video camera again).

I got to run about and help with the Open Space Sessions being run by Diana Larsen - but sadly had no time to attend.  I got to see some very interesting talks from Joseph Pelrine and Dave Thomas (although given the numbers of people I ended up sat on the floor!).

I also had a 'twitter moment' - as I was asked what my twitter id was just as the lift doors closed on my way out back to Brighton.  I never had the chance to answer but I did get the chance to twitter it. Such is life.

---

Notes from talks (hoping I have them right now):

Joseph Pelrine:

• (Sad to miss most of this talk - given he had props.)
• Every time you put a team together they will organise in a different way.
• Sensemaking involves Observation, Interpretations and Conclusion.
• People may not even be playing the same game, let alone speaking the same language.
• If you are doing Agile by the book you are not doing Agile.
• Humans don't like to deal with rules - they don't do best fit but first fit pattern matching followed by some subconscious post-rationalising.
• Process, Protocols, Ritual and Ceremonies can be both a reflection of culture and a buffer to human interaction.

---

Dave Thomas:

• Novice - Needs to know when they are done.  Experts  use different language, they use metaphor and story.   Using Drefus Model to look at programmers.
• You cannot treat people uniformly, different people have different needs.  There is no such thing as a 6-pack of developers.

QCon - Thursday

User Stories - Rachel Davies

Philosophy, stories and lifecycle of agile covered as an introductory session.

Agile aims to satisfy the customer - this does not mean that it is somehow cheaper or needs less developers.

Rachel made a very interesting point that traditional requirements documents are based on the traditional model of knowledge transfer - a model which was exemplified in teaching with lectures where the expert can pass knowledge directly to a student (who will then retain it).  The view is that knowledge can be poured out, captured, recorded and then delivered on to other people without a loss.  This view has changed, with increasing education activities focussing on reflection, group activity and tacit knowledge.  The same change could be seen in the shift from requirements capture to user stories. 

User stories are a way to work with other people, and to encourage communication.  If you haven't had a conversation about the contents of the cards then something has gone wrong - they are promises for discussions.

The Ron Jeffries three C's:
Card - Facilitate
Conversation - Discuss using agreed language
Confirmation - Acceptance Test

Traditional Form:
"As a <User Role> I need <Capability> so that <Business Benefit>"

It also helps when the story has a name.

Development Cycle:
Exploration -> Release Planning -> Iterations to Release -> Production

Create a roadmap of deployable releases - all iterations should be deployable but it may not be possible in the business case that it can be deployed each time.

Each iteration has the stories and features planned - generally estimated in story points.  There is normally more detail in the plan for the closer iterations.  At the end of each you review and refine the plan, adjusting and adding detail accordingly.  However the release dates are always fixed.

Generally in an initial planning meeting the business sponsor will present the case, allowing the development team to ask questions.  The development team can then go on to have a more detailed technical conversation.

Business people and developers must work together - and welcome changing requirements.

---

Steve Freeman - Test Driven Development

The motivation for the talk was to encourage people to go away and try it out.

So, why use TDD? - arguably because you end up with half the defects but similar productivity.  It helps to give the confidence to get the job done, and you don't need to worry so much about side-effects.

"    Write a test
"    Make it pass
"    Refactor

Tests are best named after what they will do for us and not the methods that they are testing.

Never stray far from the green bar.  This ensures steady continual progress (real not illusory), focussing on one thing at a time.   It also encourages neat, clean simple code and modular design.

Listen to the tests, analysis effort can be put into tests.  Refactoring supports design aspect by removing duplication and helping to express intent.

Code is more reliable, needs less debugging - and shorter!

Encourages test-driven management.

---

Boris Gloger - Heartbeat Retrospectives to Amplify Team Effectiveness

The idea of a retrospective is to tell a tale - the history of the team or a project.

Why retrospectives? We would like to improve what we have done in the past.

Disappointment of expectations stops learning.  Retrospectives need to occur after events to encourage learning.

6 step process
- security first
- collect facts
- ask: what went well?
- ask: what could be improved?
- who is in control?
- Prioritise activities

Security first: Prime directive - everyone has done the best job they can given their knowledge of the situation at the time.  What happened was the only thing that could have happened.

Collect Facts: Create shared team history or story.  Each person writes important event on post-it and adds to timeline on the wall, while briefly talking about it.  Only tell about your own story when you put it up, but once it is up there it becomes a team event and part of the team story.

What went well? (Creates positivity)

What could be improved?  (no manager enforcement, all ideas come from the team)

Who is in control? (who can make this happen?  The team?  The organisation?)

Prioritise activities: Create team backlog and impediment backlog.  The latter is hard, but important to make visible.  Important but hard to do and takes bravery.

Heartbeat retrospective can last 10 to 90 minutes. Use a dedicated room, not a project room, preferably in a secure environment that is not the team work area.

Some say project retrospectives should take at least 3 days - these are longer, more details as they cover a longer project in its entire history.  They also try to create solutions.  Heartbeat retrospectives are more designed for iterations.

Make conflicts visible, don't try to hide them.  However, safety is built over time as the team is built.  Hard to deal with highly charged situations in such a short time frame.  Talk about things on wall and not about each others.

By telling the story you get the information.

---

At this stage in the day the internet came back, however so did people in my room.  The talks that followed had up to 140 people and required more attention from me.  I even got to briefly work the video camera.

Am now in greatly enjoying the Martin Fowler / Dan North keynote, so had best go back to listening and stop typing.  I will have a lot of videos to watch when they go up on the qcon website.

QCon - Wednesday

Once I got past the security scanners at QCon I immediately found myself in my role as a student helper. 

Here a student helper role involves: helping with directing people, attending two meetings a day, manning the registration desk, counting heads in rooms and collecting feedback.  Mostly that means a lot of free time to attend the sessions you are interested in, and a host of free items (as well as free attendance at what would otherwise be a very expensive conference).  The exhibitor area was rife with flyers, pens, stress balls and notepads advertising some very nice companies (I am easily convinced by free toys). 

As I was not so interested in the talks I helped out on the registration desk (fending off the people from other conferences who wanted our conference bags for free) used the lovely wireless facilities, had a pleasant telephone interview for some business training, bought a replacement train ticket then headed back down to Brighton for 6pm eager to return the next day.

My photos are up on flickr here.

PPIG Work-in-Progress Workshop

PPIG Work-in-Progress Workshop, Salford 2007

After arriving in Manchester for the first time, I quickly decided that I liked it.  This was not just because the department was 6* RAE rated or because the pubs smelled of rich mahogany and had many leather-bound books.  It wasn't even because there was a giant scary santa or rumours of a dead fig tree garden on top of the giant tower that once whistled.  It just was.

---

All papers will be summarised in depth in the next ppig newsletter so I am just noting my immediate thoughts rather than describing contents.

---

Day One

Session 1: Meta-Design

Luke Church and Alan F. Blackwell (University of Cambridge) - Usable Morality – A Challenge for End User Security:
    Sporting the brilliant <rant></rant> t-shirt, Luke made an interesting case for security policies and moral terminology.  Software is sold often on the basis of moral claims: good, bad, shady, take-control, etc.

Moritz Becker (Microsoft) and Vicky Weissman (Cornell University) - Policy Languages: For the Modern World or for an Alternate Universe:
    Vicky's talk was about one thing that she, the librarians at Cornell University, the Greek Orthodox Archdiocese of America and the Australian Aboriginal community had in common.

Session 2: Design Practice

Chris Douce (Open) -  Connecting Programming with Accessibility:
    Within the talk Chris made the very interesting point (for me anyway) that Ajax is bad from a usability perspective. 

Johanna Hunt (University of Sussex) - Agile Narratives: Conversational Storytelling Across Agile Systems Development Practices:
    I managed to abbreviate my talk successfully down to 15 minutes for the benefit of all.

Cordula Krinner (Technische Universität Berlin) - Developers Anticipating Users’ Behavior During Design:
    Was amazed and impressed by actual use of proper psychological investigation.

Dinner

I missed the conference dinner, but still had a lovely, lovely dinner with good company, good cocktails and a waiter that was kind enough to chase me down the street when I left my scarf behind.

---

Day Two

Very annoyingly my right elbow decided to shift itself, so my attention span that morning was limited as I suddenly regretted having left my painkillers in the hotel. Ouch.

---

Invited Talk:Dr Judith Good (University of Sussex) - Why learn to program anyway?:
   
Sadly this talk was cancelled due to her unexpected absence, but was fortunately replaced by an interesting discussion led by Thomas Green, Judith Segal and Marian Petre on Critical Thinking in Research.  I tried to take notes, but pain caused some problems with my comprehension.  Here's what I noted:

"Science is not 'that's interesting' but 'that's odd'" (Nils Bohr).  Not 'That's interesting' but 'I wonder what that's a special case of?'

What is critical thinking?  Don't take anything at face value vs. fits with our world view.  There is no such thing as a proven theory.  The question is: Is it convincing? Do I still believe it?  Does the evidence still support it?

Evidence can be valued according to quality of data and quality of inference.

From a given hypothesis look at: definition of terms, scope, under what conditions, exception cases, what rules cause divergence?, and what are the converse questions?, why ask this question?, the six (what, why, when, where, who, how).

Hermeneutics of research. What's interesting?  What do I want to know?  What's worth knowing? What can I do?

Mantras:

• Research doesn't stop in the lab
• Soak yourself in the background
• Everything always takes a lot longer than you think it will
• If I knew what I was doing it wouldn't be research
• Keep asking 'What is the connection?'
• There is no one theory that will answer all your questions
• Those that don't know the mistakes of the past...
• Just because it is printed doesn't make it true
• Research should be fun
• Make friends with your GOST (grand overall scheme of things) and put to one side things that don't fit

Session 3: User Practice

Ann Abraham (Open University) - Sensemaking in web-based learning:
    Students use google.  I'm curious to see how this work develops, as it certainly reflects my experience of data sensemaking.

 

Nawal Alshebel and Thomas Green (University of Leeds) - Prototyping a user-interface design: the importance of tapping user knowledge:
    Nice to see iterative development of both model and system. 

Brian Bishop and Kevin McDaid (Dundalk Institute of Technology) - An Empirical Study of End-User Behaviour in Spreadsheet Debugging:
    When debugging people look at cells twice.  How odd.

Ian Entwistle (University of Salford) - Custom And Packaged Software Convergence:
    Packaged software moves to customisability while custom software moves towards fixed implementable options. 

Session 4: Cognitive Dimensions and Computer Science Education

Jiten Makan (University of Salford) - Can Cognitive Dimensions Predict User Trust?:
    Fascinating that trust is potentially a bigger factor in ecommerce than usability.  The big sites break all the rules, but when the little ones do we no longer trust them to provide the service they offer.

Luke Church (University of Cambridge) - Tradeoffs in Future Proofing Notations:
    Provoked some interesting thoughts about secondary notations.

Morten Lindholm (University of Aarhus, Denmark) - Conceptions of Object-Oriented Terms:
    Fully sympathised with his comments about the unexpected lengths of time you need for transcription.

Coffee and Closing Discussion

This went strangely well for me as I was awarded the 'Rose Elliot Prize for Time Control'.  Hilarious that I can be well timed in presentations when my timekeeping in the real world is so notoriously bad, and a wonderful side comment on my lack of vegetarianism.

I also, through some strange luck managed to be short-listed for the 'big' prize.  My name was then plucked from the bits of paper, meaning that I get money towards the cost of attending PPIG 07 this summer in Finland.  A not unsubstantial prize!

The day ended with a rather successful drive back to Brighton in under 4 hours.  Phew.

---

Sad that I broke my camera (i.e. my phone) just before this visit so what I have is poor, but some photos will follow.

UPDATE: Photos Here

XPDay London 2006

Brief, very delayed, review of sessions at XPDay 2006.  My photos are up on flickr.

Day One

Opening.

As invariably happens when I turn up early to any conference that I have not organised I end up trying to help out.  This year I was early due to my ulterior motive for coming to XPDay, that of advertising and promoting the newly viewable (but still being worked upon) Agile Narratives website (funded and supported by the Agile Alliance).   After putting out flyers and laminated poster I decided that what I really wanted was to help out with the registration process, so I took up a post handing out T-Shirts.  It appears to be a hard-to-break habit.

--

Keynote 1.

Joshua Kerievsky's talk surprised me.  He made some very interesting points in relation to selling agile, but I was not expecting anyone to start promoting teaching agile through basic e-learning...  It seemed somewhat contrary.

--

Embracing Change: An Introduction to Agile Software Development, Clarke Ching

A clear introduction based around the 'manufacturing' model of product development based on pre-existing spec.

Agile was defined as: Able to cope with change/Iterative and Incremental.

Advantages:

1. Customer requirements are prioritised
2. Increments mean working software
3. Customer can release
4. Customer can add, delete or reprioritise as needed
5. Protect schedule commitments despite change
6. Reviewable at the end of each increment
7. Reduce wastage from features which are not really needed
8. Forces early failure

Nothing new here, but good to have made sure and to have it written down.

Slides available here.

--

Making XP Crystal Clear, Andy Pols and Romily Cocking

This talk inspired some creative drawing on my part.  It, well, could have made either XP or Crystal clearer, although I did greatly enjoy the roleplay and retrospective elements. Fun, but felt like it could have used more preparation and distinguished more clearly between XP and Crystal in the talk as I didn't feel like would have made either XP or Crystal clear to a person new to the area.

--

Are We Nearly There Yet?, Ivan Moore

This session was interesting, and encouraged discussion around tracking agile projects; estimation, load-factor, velocity and burn-down charts. Sadly, due to unexpected numbers, we did not get to make paper aeroplanes, although I did get to do some nice drawings of the backs of people's heads.

--

Why is Simple So Difficult?, Facilitated by Nat Pryce and Jonathan Clarke

Very interesting talk layout.  "Normal goldfish bowl rules apply: when someone joins the discussion circle someone in the circle must leave." So, six chairs in a circle in the centre, with the rest of the room in circles around them.  If you wish to comment / join in the discussion, you must move onto one of the chairs, but one chair should always be free (so whoever is no longer directly contributing to the current turn should then move out).

I was completely sold on the fishbowl approach as it seemed to encourage discussion around many levels of the same topic in a way strongly reminiscent of the coding dojo.  You can see new people come in and shape the direction and level of discussion, and old faces return to previous themes.  Interesting and certainly worth further thought.

--

Social Monday.

Off to the pub, for a long supply of nibbles, drinks and free toys.    This perked me up, and I had a good time chatting with people.  I only had to deny working for ThoughtWorks three times.

As most things are these days it seems, the social was funded by the power of Google so I left with my obligatory "I'm Feeling Lucky" t-shirt and flashing badge.

---------------------------

Day Two

Keynote 2. 'Love in the Age of Software'

James Noble and Robert Biddle managed, rather impressively, to make part of the audience walk out of their talk in fear.  Whether it was from the content or the presentation style I could not say, although the occasional bursts into song did remain with me for the day.  They did raise some interesting points to my mind, but postmodernistic presentations are probably problematic for most professional programmers.

Points I happened to note in no particular order:

• It is important when thinking about metaphors what the reality is of the metaphor you are using.  (Waterfall is a large amount of dangerously out-of-control water plummeting.)
• 'Technical Success' is often equivalent to 'Business Failure'
• In the church of agile, agile is love
• Agile loves tools.
• We should focus on tools to help us communicate that are not machine-based tools. 
• XP Tools:
  • User Stories (Promise to have a conversation) - Often automated
  • On-Site Customer - Excused as not always practical
  • System Metaphor - Expunged from new edition
  • Planning Game - Often Resisted
• Train Wreck vs. Death March
• Lord Shannon's view of information transfer had a slight problem with noise
• Developer to Developer talk mostly mastered
• Problem with the customer developer relationship
• That's numberwang.
• Eco "No perfect form of communication exists"
• Love in an unequal power relationship has implications

--

An Introduction to Scrum, Joseph Pelrine

A good clear, professional, introduction to Scrum.

Noted points:

• Three types of uncertainty in a socially complex domain: requirements, technology, people.
• Scrum defined as empirical processes that wrap engineering processes.  Control is through inspection and adaptation.
• Origins from smalltalk engineering tools; new new product development game, timeboxes, interative, incremental development.
• Prioritise (information and value)
• Maximum flexibility
• Scrum Master is a deliberately silly name
• Stand up meeting.  No drinks. Three questions to ask:
  • What did you do?
  • What are you going to do?
  • Are there any problems or impediments to this?
• People work best when they are allowed to take responsibility for what they do.
• You need seven or less for a conversation of equals, otherwise the conversation will split into two.
• Product Owner role is vital
• Do documentation and design upfront as needed.  We do what's necessary at the time it makes sense.

--

The Toyota Way of Managing, Pascal van Cauwenberghe

A very interesting talk based on 'The Toyota Way' by Jeffrey Liker.  The following 14 management principles were discussed and illustrated:

Long Term Philosophy

1. Base your management philosophy on a long-term philosophy, even at the expense of short-term financial goals

The Right Process will Produce the Right Results

1. Create continuous process flow to bring problems to the surface
2. Use 'Pull' systems to avoid overproduction
3. Level out the load: 'Heijunka'
4. Build a culture of stopping to fix problems, to get quality right the first time: 'Jidoka'
5. Standardized tasks are the foundation for continuous improvement and employee empowerment
6. Use visiual control so no problems are hidden
7. Use only reliable, thoroughly tested technology that serves your people and processes

Add Value to the Organisation by Developing Your People and Partners

1. Grow leaders who thoroughly understand the work, live the philosophy and teach it to others
2. Develop exceptional people and teams who follow your company's philosophy
3. Respect your extended network of partners and suppliers by challenging them and helping them improve

Continuously Solving Root Problems Drives Organizational Learning

1. Go and see for yourself to thoroughly understand the problem: 'Genchi Genbutsu'
2. Make decisions slowly by consensus, thoroughly considering all options.  Implement decisions rapidly ('Nema Washi').
3. Become a learning organisation through relentless reflection ('Hansei') and continuous improvement ('Kaizen')

This ended up being one of the best talks of XPDay to my mind.
--

Metaphor and Stories, James Noble and Robert Biddle

An interesting session, which aimed more towards discussion around the problems with implementing systems metaphors and less on narrative.

Topics:

• Agile and Communication - see notes from keynote
• Jacobson's Axes (Paradigmatic (Substitution) Axis and Syntagmatic (Combination) Axis 
• System Metaphor
• Peircean Semiotics
• Semiotic Model of Metaphor
• Choosing a Metaphor
• Evaluating a Metaphor
• Actantial Analysis
• Narrative Trajectory
• Semiotic Squares

--

Social Tuesday.

This social was sponsored by Kizoom, so everyone piled off to XtC to drink and be merry.  I sat on the floor and happily chatted until it was time for me to make my way home and collapse. 

I'm certainly already thinking of options for presentations next year.  I also left with the knowledge that there are apparently only two responses to any consultancy question: 'It depends' and 'Why'...

Riessman, Analysis of Personal Narratives

'Analysis of Personal Narratives' by Catherine Kohler Riessman. In Handbook of Interview Research: Context and Method.  J. F. Gubrium and J. A. Holstein (Eds.). Thousand Oaks: Sage, 2002.

---

Riessman opens the paper with an account of a commonly found problem in interview research: the long and lengthy responses that interviewees give:

"It is a common experience for investigators to carefully craft interview questions, only to have participants respond with lengthy accounts-long stories that appear, on the surface, to have little to do with the question." 
…
"If  participants resisted our efforts to contain their lengthy narratives, they were nonetheless quite aware of the rules of conventional storytelling.  After coming to the end of the long and complex story of a marriage, a participant would sometimes say, "Uh, I'm afraid I got a little lost.  What was the question you asked?"

These responses were identified as narratives, and narrative analysis grew to be a wide and varied field. 

Riessman limits discussion about narrative research to first-person accounts in interviews in this paper.  She presents background references on the "narrative turn" and the shift in interview approaches to more relaxed styles which are open to participants' personal choices about how to organise meaning in their lives.  Narrative analysis methods are presented as one possible approach, and an appropriate one for life disruptions, politics, social movements and macro-level phenomena.  Personal narratives are acknowledged to serve many purposes - "to remember, argue, convince, engage or entertain their audiences."

She acknowledges the cultural relation involved in human storytelling, both in reference to the culture-based analysis of Ken Plummer, but also in relation to her own work.  She states:

Storytelling is a relational activity that encourages others to listen, to share and to empathize.  It is a collaborative practice and assumes that tellers and listeners/questioners interact in particular cultural milieus and historical contexts, which are essential to interpretation.  Analysis in narrative studies opens up forms of telling about experience, not simply the content to which language refers.  We ask, "Why was the story told in that way?"

Narratives are acknowledged to be located in the place, time and society in which they inhabit. 

Approaches which consider the entire life-history as narrative are placed in sharp contrast to event-centred approaches such as that of William Labov, which are in turn contrasted with "extended accounts of lives that develop over the course of interviews."  The latter are treated as an evolving series of stories which build to a larger interaction-framed narrative.  She states they are distinguished by:

Presentation of and reliance on detailed transcripts of interview excerpts, attention to the structural features of discourse, analysis of the co-production of narratives through the dialogic exchange between interviewer and participant, and a comparative orientation to interpreting similarities and contrasts among participants' life stories.

All three approaches share sequential and temporal views of narrative structure; one action is given as consequential for the next.  Structuring can also be thematic, spatial, or episodic.

Riessman acknowledges that not all talk in interviews is 'narrative' and suggests that a movement into and out of narrative structures is signalled through the use of entrance and exit talk.  However such movements are not always clearly bounded, and are co-negotiated; analysis needs to consider "paralinguistic utterances ("uhms"), false starts, interruptions and other subtle forms of interaction." 

Narratives can be analysed textually, conversationally, culturally, politically/historically, and performatively.  Riessman gives examples of people who have addressed narratives in these ways.  The analytic approach used can also affect the type of transcription required; depending on whether the focus is on interactional co-construction, culture or conflict resolution.  The researcher selects where a narrative segment starts and stops.  Thus the investigator "'infiltrates' the text."

Riessman argues for analysing narrative in terms of performance (see Langellier, 1989/2001): when we tell a story about our lives we are 'performing' our preferred identity.  This is related to Erving Goffman's (1959/1981) powerful use of the dramaturgical metaphor, where "social actors stage performances of desirable selves to preserve 'face' in situations of difficulty, thus managing potentially 'spoiled' identities."  The presumption here is that informants do not reveal an "essential self as much as they perform a preferred one." 

This approach therefore also strengthens an argument to consider linguistic performative acts; emphasis and enhancement, repetition, paralinguistic features and gestures, appeals to the audience, and body movement (see also Bauman, 1986).  Social positioning is presented as a useful point of entry for analysis, as it is open to many interpretive questions: such as who, where, how are actors positioned, what is the position of the audience, what are told as the 'turning points' and how are scenes contrasted.

The truth of a story from a performative or social constructivist stance can therefore be recognised as less important than understanding the meanings of events as located within culture and history.  It becomes 'irrelevant' as to whether the events told 'really' occurred as reported.

In the concluding comments of the paper she emphasises that the narrative approach is one of many, and should not be considered a panacea.  The approach works well with a small, detailed data set, and in contrast, poorly with a large number of participants as the analytic detail required is prohibitive and time-consuming.  She emphasises that the approach is still useful for representing and analysing the multiplicity of identities which can be presented by an informant and opening a discursive space for participants.

The approach presented in this paper brings together the study of event, experience and cultural narratives, while acknowledging the performative aspect of storytelling in co-construction of narratives.  It is a compelling argument, and acknowledges that it is only one of many possible approaches that could be taken to the text: as the approaches which can be taken to narratives are wide, diverse and can be conflicting.  Admittedly, more discussion could have been made about the varieties of approach and how they contrast, as well as other types of narrative than those found in interview contexts (which are acknowledged, but again not discussed).  There is also room for discussion about 'performances': are they effective, successful, etc. However, overall the paper presents a clear, cohesive approach to narrative analysis.

Experience-Centred Narratives

Notes take directly from `Experience-Centred and Culturally-Oriented Approaches to Narrative’ paper by Corinne Squire.  Forthcoming in M. Andrews, C. Squire, M. Tamboukou, Doing Narrative Research, London: Sage.

---

1.  What are the major differences between event-centred and experience-centred approaches?

• The event-centred approach excludes talk involving ‘narration of self’, representation itself, and co-construction.
• The experience-centred approach therefore assumes that narratives are sequential and meaningful, display transformation or change, re-present experience (reconstituting it as well as expressing it) and are definitively human.
• Unlike event-centred approaches, personal narration includes all sequential and meaningful stories of personal experience.  Storytelling is deeply social, and constitute and maintain sociality (Denzin).
• Researchers may look at hard-to-transcribe fragments, contradictions and gaps within narratives, as well as the language used.  They may draw on larger discourses or genres for interpretation.  Sometimes the approach can be expanded to also include analysis of text and image rather than just oral tellings.
• Event-centred approaches gather corpuses of stories, whereas experience-centred researchers are more likely to constrain themselves to a specific number of participants, usually small.

2.  What characterises the Ricoeurian and Brunerian account of narrative?

• Ricoeur presented the experience-centred notion that “time becomes human to the extent that it is articulated through a narrative mode,” and that narrative is co-constructed ‘practical wisdom.’  Bruner describes narrative as transgression and restoration of canonic understanding.
• For Ricoeur, top-down and bottom-up interpretive procedures are used to address the hermeneutic circle of interpretation.  For many researchers (e.g. Freeman) the hermeneutic circle never closes.

3. What are some of the difficulties faced when applied to social science research?

• Ricoeur’s definition of narrative is an ideal. 
• Can we identify a ‘good story’?  Chamberlayne, Crossley, Holloway and Jefferson seem to think so, but this prescriptive approach may overly narrow our criteria.
• Do we need our stories to have endings or futures built into them?  Freeman, for example, thinks that stories are often tied to possibilities within life. 
• There is debate over whether the Ricoeurian approach can be extended to look at the subconscious in relation to psychoanalysis. Some researchers argue that the unsayable stands outside the concerns of narrative research.
• Time is still a focus in the Ricoeurian approach, and this is still restrictive – space and theme may also be powerful organisers of human experience.
• There is a loss of attention to language itself, emphasis is on meaning.
• There is debate over how linked to actual experience stories are.  Following Ricoeur, Venn notes that stories form a third space between the real and the imagined.

4. What are the abiding benefits of taking this kind of approach?

• The openness, flexibility, and reflexivity of this approach are some of the most useful features.

5. What culturally centred approaches are there?

• Socially and Culturally-Oriented approaches include those espoused by Plummer and Riessman.
• Plummer thinks that intimate disclosure narratives and the interpretive communities that they build are highly significant personally, socially and politically. Interpretive communities have to exist for stories to be told, and build collective identities.
• Narrative for Riessman is a mode of interpersonal, social and cultural positioning and negotiation.  An interview is a co-constructed narrative – and a narrative is the full personal narrative told by the interview.  Riessman’s framing brings together the study of event, experience and cultural narratives.

6. What Problems are there with these approaches?

• Culture is not static, and genres are always changing.  Genres will be understood differently by different people and cultures. 
• The cultural approach has also been commented to neglect individuals’ own stories. 
• This approach does not fit well with postmodern approaches to constructed, distributed and multiple subjectivities. It is possible to argue that the ‘social construction of self’ and the ‘expression of self’ that are assumed in both Plummer’s and Riessman’s work rely on different conceptions of self that cannot be reconciled (modern and postmodern respectively). 
• Many equally persuasive readings are available for any story (Freeman) and interpretations vary across time and place (Andrews, Riessman).
• The approaches within this banner are wide, diverse and can be conflicting.

Concurrent vs. Paired

A Field Study of Developer Pairs: Productivity Impacts and Implications by Allen Parrish, Randy Smith, David Hale, and Joanne Hale
Published in IEEE Software, September/October 2004

The authors build from a previous study of programmer productivity as team size increases, where they had concluded that increased concurrent work on core modules leads to decreased productivity.  They reconsider their data for concurrent working pairs in response to positive findings from pair programming.  The authors conclude that the role-based coordination protocol associated with agile software methodologies overcomes a significant productivity loss otherwise associated with concurrent software development pairs. A good article with some pertinent points raised.  The data from the field study supports an interpretation which says that concurrent work on a module reduces productivity.  The metric used for this data set does not provide definitive results as the type of collaboration for the concurrent work is not available (i.e. developers could have been in different offices, not in communication, etc.), but the authors propose interesting avenues for further investigation based on this finding.   

Reviewed for the Agile Alliance

Marginalizing Problem Solvers

Do Agile Methods Marginalize Problem Solvers? by Victor Skowronski
Published in IEEE Computer, October 2004

This short professional article comments that a software development methodology should take advantage of programmers’ strengths and avoid their weaknesses.  It argues, by reference to the working styles of Thomas Aquinas and Isaac Newton, that agile methods may do the opposite for certain working styles – that of problem solvers.  The author questions whether agile methods provide the best environment for the best programmers, and indicates that a good problem solver who lacks people skills appears to be less competent in the eyes of agile methods proponents.   "Competent in this context means that the programmer possesses real-world experience in the technology domain, has built similar systems in the past, and has good people and communication skills."  The four phases of problem solving (Preparation, Incubation, Illumination, and Verification) are discussed in terms of the difficulties faced at each phase for a problem-solver in an agile environment.  The paper makes a really interesting observation, argued by historical anecdote.  It reads occasionally dismissive of agile without supporting argument, but it would still be interesting to see further work in this area.

Reviewed for the Agile Alliance

 

VBM and Agile

Value-Based Management and Agile Methods by John Favaro
Published May 2003

Describes the five principles of Value Based Management (VBM) and details how the principles of VBM are aligned with those of Agile methods: the operating principles embodied in agile methods make operating parameters explicit, while the financial and strategic principles in VBM make profitability parameters explicit.  Particular attention is focused on financial metrics for measuring value creation and efficient resource usage. The five principles of VBM are neatly outlined, but there is a lack of consistency in the paper about how they relate to Agile – the paper ends up being an expression of similarity for each separate principle, but personally fails to draw any conclusions about what lessons or interest could be drawn from the similarity between the operating principles of agile and the principles of VBM.

Reviewed for the Agile Alliance

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.