TRABAJOS REALIZADOS 1. Por tipo de auditoría

5.6.1 Openness to ideas

Participants spoke not only about why ongoing communication is necessary but also about how: the essential ingredients to make such communication successful. An imperious attitude is not helpful:

“’I am God, this is how you do it’. No.” (Participant D)

The value of asking questions is interlinked with the theme “good at helping others”; there needs to be someone willing to answer, and do so constructively. Participants commented on feeling “lucky” and appreciative for the help they have received. It is not surprising that they find it useful when others are willing to help them, but the benefits go beyond an individual getting answers; it keeps the team aligned:

“Some people can be harder to approach than others. And it makes it a lot easier if you can ask a question, frequent questions and small questions, then you realise you’re, you’re aligned and both going in the same direction, following the same path. ” (Participant B)

For conversations about a particular piece of code, being open to discussing suggestions is an important theme. In a properly open conversation, it could be any or indeed all of the contributors who learn from the exchange. If discussion is shut down, an opportunity to change things for the better can be lost:

“You might come up with an idea and …somebody says ‘there’s a better way of doing this and this is not the best way because’ …’ then you can say ‘well that’s a learning experience’ you know, you can learn from that.” (Participant F)

“You say ‘I don’t understand this bit of code’ and their response basically is ‘well that’s because you’re an idiot’. And by the time six people have knocked on the door and said ‘I don’t understand this bit of code’ you really think they should start getting the hint that it doesn’t matter how clever they are compared to the rest of humanity, they’ve gotta write for their audience.” (Participant G)

5.6.2 Attachment

Openness is impossible for someone too attached to an idea. The card topic

from which the “owns code” theme developed was originally envisaged in terms of territorial behaviour, creating code that will be difficult for others to understand when the need arises because no-one else has been allowed to touch it. But the card was more often talked of in terms of the programmer becoming too attached to code, and thus reluctant to change or discard it:

“They build an attachment to what they themselves have produced and a particular way of doing things.” (Participant H)

The attachment may extend beyond their own code into a wider insistence on people doing things “One True Way”. One participant outlined the difficulty of resolving the disagreements this can provoke:

“Sometimes they can end up butting heads for no good reason really other than you’ve both learnt different ways …If there’s no statistics to say which ones are actually best then all you’ve got is what you’ve been told and what you’ve experienced and if both of your experiences have been good then there’s no real argument to be had. All the pluses and negatives are really theoretical because you’ve both had success.” (Participant H)

This observation hints at the importance of explaining a logical reason for the adopted approach. Sometimes the result of a question will be a change to the code that provoked the query. But often it will be the questioner’s own knowledge that changes; things become easier to understand and work with when they learn about the reasoning:

“Sometimes what you find is, people say ‘This is how we do it’. ‘Why?’ ‘Because it is is.’ ‘But why?’ ‘Because it is’ …If they can sort of quantify and say ‘This is why, because of all these factors’, then you go ‘Oh right, OK, I understand now.”’ (Participant D)

5.6.3 Mature, professional conduct

For conversations to occur, those with questions or feedback must be willing to tackle the issue, even when faced with someone who is not open to discussion:

“You have to be strong enough to question that person even, whether they’re going to take umbrage or not to that.” (Participant E)

“If no-one sort of goes to him and says, you know, ‘Why have you been doing it that way?’ then it sort of gets forgotten about and then it just rolls on day after day, doing the same sort of thing. Whereas I think people need to go ‘Hang on a minute, why are you doing it like this?”’ (Participant D)

When they tackle it, they need to do so constructively and diplomatically; it should not come over as an attack on either the person or their code. Similarly, a person receiving feedback should not take it personally or be upset:

“So it’s not all negative or we say ‘Have you considered this?’ rather than ‘This is rubbish’.” (Participant H)

“If you don’t talk about things and say ‘Ooh, don’t talk to such-and- such, it’ll upset him’, well, I dunno, grow up, man up, you know. It’s, we’re all adults here and we’re all trying to do something for a customer.” (Participant D)

“There’s someone in the current role who is very stubborn and that’s not helpful if you’re trying to come to something together. So he has this ability to make himself come across as affronted by any questioning if you can do it in a way where you can separate the person from what you’re talking about you can have a fantastic discussion and we actually promote that, that’s fantastic.” (Participant E)

The phrase “trying to come to something together” summarises the essence of participants’ talk about fruitful technical dialogue: it is not about ego or point scoring but moving forward with an appropriate technical solution and a better understanding. Programming is an exercise in problem solving.

5.6.4 Attributions

It is a human tendency to infer causality for the behaviour of others; in psychology this is termed attribution. Sometimes participants expressed thoughts about why their peers act as they do. While the focus of this study was to identify which

behaviours are significant, the perceived reasons behind them might help to inform any intervention intended to change behaviour, although they should be interpreted

with caution. There is psychological evidence for an Actor-Observer effect in

attribution (Hogg & Vaughan, 2011), in which our own behaviours are attributed to external factors (such as those in §5.7.2) and others’ behaviours are attributed to their internal disposition. This perceptual bias may mean that the perceptions are erroneous (Tashakkori & Teddlie, 1998).

Figure 8: Extract from template: attribution

Of the attributions participants made (see Figure 8 for the themes from the final template), some are simply about experience; never having seen later stages of the product lifecycle, for instance, means limited opportunities to understand the consequences of actions taken in the earlier stages. But experience too has its drawbacks if it becomes ingrained as learned habits and reluctance to change. Conservatism also manifests itself in failure to look for alternatives; conversely, good programmers learn new things and update their toolkit so that they have a wider range of ideas to call on. It is possible, though, to embrace new ideas too enthusiastically; a healthy degree of scepticism is needed for the “flavour of the month”, together with an appreciation that introducing new technologies will affect others:

“And you have that sensation quite often, finish a project and you’ve just, you finally got to grips with everything that was introduced last time, only to think, woah what’s this?” (Participant B)

Getting the balance right requires an interest and openness for new ideas combined with a collaborative approach to change:

“Everything comes down to interacting with people ultimately …I’ve learnt over the time that just coming in and saying ‘This is the way we should do it you idiot’ isn’t, funnily enough doesn’t get things to work out the way you’d hope they would. So gradual change or something, or convincing people you’re competent and then trying to talk them around is sort of the way to go.” (Participant G)