This research is concerned with the impact on software developers of peer behaviour, but professional developers write software for an employer. Some themes emerged which illustrate the significance of the issues for business and the environmental factors that can themselves help or hinder.
5.7.1 Consequences for business
To summarise briefly, programmers want their peers to communicate open-mindedly with colleagues for timely feedback and to put themselves in the shoes of others in order to include meaningful identifiers within the code and helpful information in the framework of artefacts that surround it. The emotive words they use suggest that these things matter to them.
Figure 9: Extract from template: business consequences
What businesses want from their software is that it works, is delivered on time and makes a profit. Why should it matter to them just how it was done? The answer lies in the final template themes shown in Figure 9. Even if software were written, delivered and forgotten there would still be reason: good software developers who leave because of low morale are not easy to replace. But software is revisited, often time and again, as it is fixed, updated, extended or re-purposed. Participants describe how peer behaviour can: make tasks harder or easier; create tasks that could have been avoided; cause or prevent problems. They also mention how these issues affect the one thing that is generally the major cost of a software project: their time.
“ Working around it all, effectively re-writing code that does the same thing somewhere else.” (Participant H)
“Rather than doing a complete job on it, it’s a bit of a quick fix and then you get, you come around to it about three times again and it’s a bit like ‘oh maybe we should have just sorted it out in the first place’.” (Participant C)
“In maintenance work it’s pretty much about being able to speed read somebody else’s code …you scroll down and each method comes up,
‘Yep I see what that does, I see what that does, I see what does. Yes, that’s fine’. Whereas if you’ve got a big wodge of text, suddenly you’ve got to stop. You know, ‘What exactly does this do?’ It just slows you down.” (Participant A)
5.7.2 Confounding and mitigating factors
While the focus of the interviews was on peer behaviours, such actions do not occur independently of their context. Sometimes participants mentioned how an issue does not affect them as much because it is mitigated by factors in their workplace. Conversely, there were problems which can be created or exacerbated by external pressures. These themes from the final template are shown in Figure 10.
Figure 10: Extract from template: external factors
The beneficial factors included practices the team follow, such as a stringent process of code review. Similar benefits were cited for pair programming. In both cases the work is subjected to timely scrutiny, allowing a course correction for any errant software.
“It’s an area also where pair programming helps tremendously. If one person is writing the code and somebody is looking at it and saying ‘What are you doing? What’s that? No, that can’t be right’. So pair programming or code reviews and so on, all that helps.” (Participant A)
Unit tests are also beneficial, beyond just checking the code’s correctness. The cards about trying to leave a module a bit better and not being constrained by existing code both elicited some equivocal responses; refactoring can be desirable but nonetheless inadvisable due to the risk involved. Because tests reduce that risk they make it easier for improvements to happen:
“Tests to check existing behaviour …once you’ve got those you can change it however you want and make it much nicer.” (Participant H)
Tests were also mentioned as another kind of executable documentation, giving clues as to what the code should do. However, this must depend to a degree on how well the test is written. One participant’s anecdote is a salutory reminder that following policy rules does not guarantee that the practice is properly carried out:
“We’d poke him to write unit tests and the unit tests would appear to work, but if you looked closely he’d written the unit test by running the function, looking at what came out of it copying and pasting out the assertion.” (Participant G)
The other main theme for beneficial factors was the team’s environment. Communication is of enormous importance, and live conversation the preferred medium, avoiding what one participant called “the electronic warpath”. As they spoke about their interactions with colleagues, it was evident how participants’ office environments (all of them open plan with no or low screens between desks) facilitated this: they are able to “push back”, “lean over” or “turn round” to a colleague when they have a question. One described how they have deliberately removed high screens from between their desks and no longer have to “meerkat up” to do this.
5.7.3 Value of the reflective discussion
Participants not only responded to questions but also volunteered their thoughts on the process of taking part in the interview. Their comments suggested that they appreciated the opportunity to step back and look more deeply at what most affects them. One found it “a really interesting idea” to focus a discussion not on the usual technical details but “What makes you irrationally angry about a codebase or a team of coders? What makes you overjoyed?” (Participant J).
Reflecting at this level was evidently rather different from the content of the
discussions that normally take place. Participant J spoke about the need “to
circumvent all the nonsense arguments” about issues such as use of whitespace, a sentiment echoed by another in describing “pet peeves” that assume undue prominence at the expense of more substantive and troublesome issues:
“Where you put things like the braces in C and C++, whether you have a space between the if and the bracket. They do get incredibly wound up about things like that. And yet they won’t get too wound up about not having sufficient information on the bug report.” (Participant K)
Citing another example, the practice of encapsulation, Participant J demonstrated how even talking about substantive principles can fail to hit the mark when the conversation does not help people to understand why and how those principles
matter : “[Encapsulation] is one of those deceptively simple words …He listened to all the words and completely missed the point.”
It is evident from their feedback that the participants do not experience fruitful discussions about the impact of working practices in their normal working lives.