PROBLEMAS DE REVELACIÓN

The study set out to answer the research question: what is the perception of experienced programmers on the peer behaviours that help or hinder them in their own tasks? To elicit these perceptions, it encouraged programmers to draw on their own extensive experience and used card sort materials to help prompt them to consider the wide range of activities that their jobs involve.

The researcher’s own history as a programmer also played a significant role in this process. Participants spoke as to a peer, using the language of the profession. This gave the interviews the quality of a frank discussion between fellow programmers, without the baggage of colleagues at the same workplace or the commercial constraints of speaking to an outsider, affording a very intimate insight into the reality of working on a software development team.

The picture that emerged was unexpected. The anticipated themes, as represented by the topics on the cards, included considerable material drawn from guidance on how code should be written. These are not unimportant; few topics were commonly deemed “neutral” for their effect on participants’ progress. But the things that cause them most hindrance and frustration, and the things that make the job run more smoothly, are not in the fine-grained details of lines of code. Syntax does not excite much passion; it may sometimes be used in a way that is less easy to read, but it is never ambiguous. What makes most difference is how readily information is available.

At an architectural level, this means: writing only code that is necessary, not reinventing the wheel, and creating a “natural” solution rather than a “clever” one. To use participants’ metaphors, others reading the code should not have to machete through a jungle, grapple with a monster or ask “Why is this here?” These needs are consistent both with the findings of Sillito et al. (2006) about the practice of navigating through code and with the problem of violated expectations as described by Hansen et al. (2013). Meeting the needs of an imagined future reader (possibly

even one’s future self) calls for some empathy, but also benefits hugely from getting an outside perspective in the here and now. As some participants suggested, the practice of pair programming can help with this. Though not much mentioned in the study, regular code reviews could also offer the opportunity for dialogue; perhaps they did not feature more because this is not the manner in which they are usually conducted. When mentioned, it was as a bottleneck waiting for a reviewer’s time, and it appears that some companies conduct their reviews as an electronic monologue. But interaction with colleagues is essential for the timely feedback it provides; no-one should be reluctant to have a dialogue about their work, to speak up or to listen.

No participant called for more, or better-maintained, text documents to provide the information they need. No doubt they would agree that “only the code tells the truth” (Sommerlad, 2010) or at least that, because it defines what the program does, it is guaranteed to be a reliable source of that information. But they do want better information about things that are otherwise hard to deduce. Good identifiers help them to read the code by complementing the grammar of the syntax with meaningful nouns and verbs. Unit tests provide almost as good an account of how the unit should behave as the code itself provides of what it actually does. Automated scripts can dependably show them how the software is built, tested and deployed.

Should something go wrong, participants are skilled at diagnosis if they are but given a clue about the symptoms. The messages recorded in tools supporting the development of software are worthless if they do not offer this. Bug reports and commit messages should share the information that is possessed by their writers; the study shows that like the code itself, these messages do have readers. This is true, too, for logging messages. They fail in their purpose if the writer does not put themselves in the reader’s shoes and ask themselves “What would I need to know?” Feedback from the study participants was that the interview had been enjoyable and interesting. Often this came as they were leaving, but one commented while the recording was still running: “Thank you for listening! …I feel much better now, thank you.” (Participant J). It is unusual for this community to be able to speak freely about their work to an interested, independent, non-judgemental peer listener. Conversations with colleagues can be subject to many workplace constraints (office politics, one’s reputation, company culture and so on), while commercial considerations and the technical knowledge of the listener limit the extent to which work can be discussed with friends and family. Furthermore, conversation with a non-specialist is unlikely to flow. They can offer sympathy, but not empathy with

the particular frustrations of a particular technical scenario.

However this also highlights that care is needed in interpreting the data. People who volunteered to spend 90 minutes talking to a stranger about their work are probably not among the most reserved and uncommunicative of software developers. The value they place on communication may not be shared by all their colleagues. Nonetheless they made a good case for its importance, talking not about personal preferences for workplace conversation but their experiences of problems avoided and solved early on, or discovered too late. Their comments on the process of these reflective discussions suggest that it would be useful to have them with their colleagues too.

Nonetheless the findings have some parallels with Curtis, Krasner, and Iscoe (1988); the software development professionals they interviewed did not identify exceptional designers by their skill at producing software. Instead, expertise was marked by knowledge of the application domain, time spent communicating with other team members and commitment to coordinating all individuals’ efforts towards the overall success of the project. Peer perceptions such as these are harder to collect, but contribute to a much richer picture of successful projects than quantitative measures alone.