Communication in any software development community can be complex, nuanced and varied. Making a communication choice can have unintended consequences or can be a
strategy for successful interchange of ideas and unambiguous decision-making. We offer two examples of communication in software development, one from academia and one from industry.
Vignette 1:
Setting: As part of their senior capstone project, a team of three software engineering stu-dents are working on a project for the US Navy. Their client and technical expert is Hank Taylor, a professor in the Mechanical Engineering department. An earlier team had met with the client several times and tried but did not succeed in producing the code needed.
The current three person software development team has taken over from them and is at-tempting to finish the project with Hank. Several weeks into the project, the current team finds itself facing similar issues to the first team - they are behind schedule in presenting a requested analysis of the existing legacy code.
In this vignette, Denise, one of the software engineering students shares a rough hand drawn data dependency and control flow chart (see Figure 1.1 on page 3) of the legacy code with Hank. They use the hand drawn chart to point at areas of the code represented by boxes, to be able to clearly articulate their questions and responses, using the chart as context for their questions. Together, they read the chart and mark it up as they go along.
Hank (client): Is this your chart?
Denise (student CS team member): Yes
Hank: It looks exactly like his (another chart from a company that is a navy contractor, to keep track of the code)
Denise: No, his chart is much nicer.
Hank: So have you folks started ‘divvying’ it up?
Denise: This is where we need some help. So this is what happens in the code (pointing at Denise’s chart) [Denise explains on her chart that she has color coded based on which blocks are her responsibility and how the chart describes the blocks]
2
Figure 1.1: Denise’s hand-drawn chart
Hank: Can you show me some example within the code? This is great. Don’t throw this out. Is this hand-drawn?
Denise: Yes, I love the colors.
Vignette 2:
Setting: Audacity is a popular, open source, cross platform, recording and audio edit-ing tool. The Audacity project has been runnedit-ing for many years and has been exercisedit-ing software development communication using email as the primary means of communication and decision making. The project is profoundly distributed in nature, with members from different countries. They have a core team of four to six people and receive code con-tributions from an assortment of programmers. Anyone in the developer list can start a discussion. Some of the participants on the forum may be regular contributors but not on the Core Team. The participation ranges from extremely regular to sporadic for some of the developers. The replies on the forum can be complex in style and are often inline with varying degrees of quoting.
In the following email exchange, Campbell is an occasional contributor and Benjamin,
who has been regularly contributing for two years, has recently been inducted into the Core Team. Cambell brings up the question of code style and Benjamin enthusiastically agrees with him. Leland and Vaughn are long time contributors in the Core Team where Vaughn could be considered the most active on email. Vaughn disagrees with the suggestion and eventually reveals that this type of discussion has occurred before and decided.
The project has just wrapped up a code freeze and the developers have some time to reflect on the bigger picture. This is a discussion post code freeze time when developers have time to reflect on the bigger picture. Benjamin supports another new developer Campbell, who brought up the idea of following standard code style in the programming. The idea is debated where some relative newcomers are in support of imposing coding standards and some of the more experienced developers in the community are against the idea and do not want to continue the discussion as this issue had been discussed and decided before.
Campbell Barton wrote:
Hi,
I was curious if Audacity has a preferred style guide.
---Richard Ash wrote:
Hmm, google: audacity code style first hit
http://wiki.audacityteam.org/wiki/CodingStandards
(and link in the second section of the Developer Guide).
———————–
Benjamin Drung wrote:
4
The coding standard says:
three spaces per indent
Why? Every other software project that I know uses either two, four, eight spaces per indent or tabs. Some code/text editors do not support three spaces per indent.
---Leland wrote:
Here’s a little more background:
http://audacity.238276.n2.nabble.com/How-about.html
And I’m sure it was discussed way before that. For those that don’t know Dominic was one of the original authors of Audacity.
---Benjamin Drung says:
Maybe it’s time to discuss it again. Old developers retired and new joined. So the overall preference could have been changed. Who of the Audacity developers has strong opinions regarding coding styles and who does not care (as long it’s consistent)?
Three spaces for indentation was a compromise between two and four. Who is for two spaces and who is for four?
———————–
After several emails, Vaughn wrote in response to Leland:
On 2/8/2013 2:48 PM, Leland wrote:
On Fri, Feb 8, 2013 at 2:01 AM, Vaughan Johnson
We’ve had many developers over the years who participate for a short (sometimes long, often infrequent) time, then move on, or become lurkers. (Ahem, like the guy who started this thread, and admitted he’d diverged from prior style when he contributed - much love!)
If this is a reference to me, then I was just doing what I thought you wanted...to keep quiet.
(Vaughn:) Thanks, Leland. I appreciate that, too.
Your original response was quite clear and nothing more needed to be said. Basically, the Audacity project is flexible, to some extent, when it comes to coding style.
Why have you kept the thread alive? It’s really simple...don’t respond.
(Vaughn:) I kept alive to engage the new posters, who apparently weren’t getting what I said in my original response, and diverged into other topics. Sorry it’s not more pleasant, but I get frustrated repeating myself and being argued against the same thing. I’m glad you found it clear what I was saying, but yes, I did feed the troll.
Thanks, Vaughan
These seemingly ordinary scenarios are complex under the surface. They are a product of choices, conscious or unconscious, on the part of the participants. In the capstone project vignette, the use of an artifact, in this case Denise’s chart which started off as a tool for de-veloping her own understanding of the legacy code, to facilitate a design and code specific technical discussion is an innovative way to disambiguate questions and explanations about
6
code. The artifact also expresses to the client the ability of the student to understand the code. It gives the student a chance to show her work and inspire confidence in her abilities.
When the same hand drawn chart was used in a class activity in Team Software Project as an artifact of software development, many students reacted to the chart by calling it “messy and unprofessional” and “something (we) would never use with a client”. However, in this instance, Hank, the client was very impressed with the chart and in turn with Denise, the student. He exclaimed that now Denise is the person who knows the most about the code.
Upon learning of the context some more, the capstone project students understood its place as an artifact for personal consumption, therefore messy, but being used to demonstrate knowledge to the client.
In the Audacity vignette, when Benjamin supported the question of enforcing style guide-lines, he was taking initiative and encouraging a discussion. However, as the discussion ran very long and eventually became unpleasant, it did not serve the originator in expressing his vision and attempt to foster a healthy discussion. Instead, some of the more experienced developers in the community were annoyed at the persistence of the discussion that they were trying to resolve quickly.
Also, at one point Benjamin poses a question about who supports which decision regarding coding style. “Three spaces for indentation was a compromise between two and four. Who is for two spaces and who is for four? ” This is an awkward way to move the discussion forward before the more mature developers on the project have even given assent. The first issue with this type of statement is that it is a premature challenge to the status quo of no specific coding style and it calls for broad input which is awkward in a medium like email, where a specific question about who supports 2 spaces versus who supports 4 spaces for indentation, when the current standard is 3 spaces. This raises the questions: what would be a good alternative to the poll taking, and how does one determine that the poll taking is done? In this project, email poll taking is a common practice. However, questions do not often get more than a few responses, and those responses can be a factor in the decision, dependent on who supports it.
These are both examples of communication that have a significance beyond just the simple act of the communication, influenced by the context. Both are cases of communication which is strategically planned overall – planning a meeting, preparing a chart, starting a discussion about code style; however the participants have to improvise the specifics of the conversation, thinking tactically. The details of the communication require consideration, and there is no template or process that participants could follow to determine that. They can plan what the activity is going to be, and while engaged in the activity, they make smaller choices about their communication and can also have a great impact on the outcome of their communication.