Tag Archives: Software engineering

Our paper, “The Role of Domain Knowledge and Cross-Functional Communication in Socio-Technical Coordination”, to be presented this coming week at ICSE2013!

So, our paper at the International Conference on Software Engineering, titled The Role of Domain Knowledge and Cross-Functional Communication in Socio-Technical Coordination, will be presented this coming week in San Francisco. Daniela is going to be presenting this paper on Thursday, May 23 at 1:30 PM in Grand Ballroom B!

The preprint of this paper appears on my blog. The main story is that we examine how diverse roles in two teams in Brazil working on requirements and their related artifacts coordinated along task dependencies using a case study method, and report on how knowledge and work dependencies affect their work.

There are a number of other great papers that are appearing in the same session, including two co-authored by Prem Devanbu. It’s a good session to be at, in my opinion.

Hope to see you there!

The Whats and Hows of Programmers’ Foraging Diets: What Types of Information are Programmers Looking for?

Information seeking is one of the most important activities in human-computer interaction! One of the most influential theories in understanding, modelling, and predicting information seeking is information foraging theory. In our research, we want to understand what kinds of diets – that is, the types of information goals programmers seek while debugging. By investigating the information diets of professional programmers from an information foraging theory perspective, our work aims to help bridge the gap between results from software engineering research and Information Foraging Theory foundations as well as results from human-computer interaction research.

A pork chop taken by johnnystilletto on Flickr

Is this tasty?

A head of broccoli by Jim Mead

Is this tasty?

My co-author, David Piorkowski, is travelling soon to Paris to present our latest work: “The Whats and Hows of Programmers’ Foraging Diets”. It’s a great time to expand on this paper. Here’s the PDF Preprint!

Our Method

We had two coders examine video of nine professional programmers to identify what exactly they were looking for when trying to fix a bug in an unfamiliar open-source program. We tried to identify their overall diet by identifying if they asked questions (and received answers) belonging to one of four categories: (1) finding a place to start in code, (2) expanding on that initial starting point, (3) understanding a group of code, or (4) understanding groups of groups of code.

What is a programmer’s diet while debugging?

Overall, we found that programmers spend 50% of their debugging time foraging for information.

Surprisingly, even though all participants were pursuing the same overall goal (the bug), they sought highly diverse diets. For example, Participant 2 asked mostly about groups of groups, Participant 3 asked about finding a place to start, Participant 5 didn’t really ask about anything at all, and Participant 6 also looked for a place to start. This suggests a need for debugging tools to support “long tail” demand curves of programmer information.

How did a programmer consume these diets?

How exactly did programmers go about finding what they wanted to consume?

Again, participants used a diverse mix of strategies. Participants spent only 24% of their time following between-patch foraging strategies (such as code inspection or simply reading the package explorer straight up-and-down), but between-patch foraging (such as doing data flow or control flow) has received most of the research attention.

Surprisingly, search was not a very popular strategy, accounting for less than 15% of participants’ information foraging – and not used at all by 4 of our 9 participants—suggesting that tool support is still critical for non-search strategies in debugging!

Whats Meets Hows

Participants stubbornly pursued particular information in the face of high costs and meager returns. Some participants followed a single pattern over and over again, using the same strategy. For example, in the cases that involved a programmer looking for Type 1-initial goals, participants used code search and spatial strategies extensively but not particularly fruitfully. This emphasizes a key difference between software development and other foraging domains: the highly selective nature of programmers’ dietary needs!

Takeaways

Thus, we considered what programmers want in their diets and how they forage to fulfill each of their dietary needs. Our results suggest that the diet perspective can help reveal when programming tools help to reduce this net demand—and when they do not—during the 50% of debugging time programmers spend foraging.

References and Links

Are you going to be at CHI 2013? Where and when is David’s talk?  It’s on Thursday, May 2, at 11:00 in Room Blue… be there!

D. Piorkowski, S. D. Fleming, I. Kwan, M. Burnett, C. Scaffidi, R. Bellamy, J. Jordhal. The Whats and Hows of Programmers’ Foraging Diets, to appear in ACM Conference on Human-Computer Interaction (CHI), Paris, France, 2013. PDF Preprint

Our paper on the CHI 2013 web site

And… in case you haven’t seen it yet, the video preview!

Picture of tasty pork chop by Johnny Stilleto. Picture of tasty broccoli by Jim Mead.

The Role of Domain Knowledge and Cross-Functional Communication in Socio-Technical Coordination

Our recent ICSE paper has been accepted and I’ve made it available online here as a pre-print version: ICSE2013-DomainKnowledge-Paper38.pdf.

The paper discusses an investigation into the spread of domain knowledge, as well as specific cross-functional knowledge across two different global software teams. Essentially, there are two kinds of “structures” internally that may guide project communication. First, there’s the cross-functional communication structure, where people within the same roles are allowed to communicate but people of different roles need to communicate via certain team members (usually team leaders) to avoid misunderstandings. There’s also communication across task assignments as well.

One team had relatively experienced team members and a dense communication structure whereas the other team had inexperienced team members and a siloed communication structure. We identified that people with domain knowledge were more often involved in communication. We also identified brokers in both teams who mediated knowledge from person to person – these brokers spanned multiple application domains in our case studies. Surprisingly, team members followed the cross-functional communication structure, but they did not always follow the expected task assignments. We hope these results can help facilitate knowledge sharing and knowledge management in these types of teams.

Abstract: Software projects involve diverse roles and artifacts that have dependencies to requirements. Project team members in different roles need to coordinate but their coordination is affected by the availability of domain knowledge, which is distributed among different project members, and organizational structures that control cross-functional communication. Our study examines how information flowed between different roles in two software projects that had contrasting distributions of domain knowledge and different communication structures. Using observations, interviews, and surveys, we examined how diverse roles working on requirements and their related artifacts coordinated along task dependencies. We found that communication only partially matched task dependencies and that team members that are boundary spanners have extensive domain knowledge and hold key positions in the control structure. These findings have implications on how organizational structures interfere with task assignments and influence communication in the project, suggesting how practitioners can adjust team configuration and communication structures.

Daniela Damian, Remko Helms, Irwin Kwan, Sabrina Marczak, and Benjamin Koelewijn. “The Role of Domain Knowledge and Cross-Functional Communication in Socio-Technical Coordination”, to appear in the International Conference on Software Engineering (ICSE), May 18-26, 2013, San Francisco, USA.

Download ICSE2013-DomainKnowledge-Paper38.pdf.

CHI2013 Paper Accepted: The Whats and Hows of Programmers’ Foraging Diets

In more news from the conference acceptance front, our CHI paper “The Whats and Hows of Programmers’ Foraging Diets” has also been accepted. This paper examines how programmers forage for information while they are debugging and in particular pays specific attention to the types of information they seek. These participants were trying to track down a Java bug in JEdit using Eclipse.

The findings of this paper include the fact that participants used very diverse strategies to pursue the same task, that the participants’ enrichment strategies of searching and breakpoint debugging (that is, modifying the environment by providing information) were very repetitive, and the fact that participants often foraged for information within a single information patch (especially participants who scanned the package explorer and the outline view thoroughly).

I’ll do a more detailed writeup on this paper soon, when the camera-ready version is prepared!

D. Piorkowski, S. D. Fleming, I. Kwan, M. Burnett, C. Scaffidi, R. Bellamy, J. Jordhal. The Whats and Hows of Programmers’ Foraging Diets, to appear in ACM Conference on Human-Computer Interaction (CHI), Paris, France, 2013.

ICSE13 paper accepted: The Role of Domain Knowledge and Hierarchical Control Structures in Socio-Technical Coordination

The official notifications for the International Conference on Software Engineering (2013) have been sent out. ICSE is an archival conference that is one of the top conferences in the field. This year, there was an 18.5% acceptance rate.

The paper is about how the presence of domain knowledge among team members affects how people coordinate in a software team. In addition, many of these teams have other hierarchical structures in place and recommend that certain people limit communications with others to follow team boundaries. We investigated two projects in a large global software organization and contrasted how they structured their teams and thus the resulting communication patterns. Some of the techniques they used to “spread” domain knowledge in the team were by incorporating new hires into the project, rotating roles, and making knowledgeable team members easily reachable.

I’ll give a detailed account of the paper when we get in our camera-ready version (which isn’t due until March)!

D. Damian, R. Helms, I. Kwan, S. Marczak, B. Koelewijn. The Role of Domain Knowledge and Hierarchical Control Structures in Socio-Technical Coordination, to appear in IEEE International Conference on Software Engineering (ICSE), San Francisco, USA, 2013.

To Talk or Not to Talk: Factors that Influence Communication around Changesets

Adrian at the ACM Conference on Computer-Supported Collaborative Work is presenting “To Talk or Not to Talk: Factors that Influence Communication around Changesets”. He went to Zurich to work with the IBM Rational Team Concert team located there, and interviewed them, applied surveys, and did personal observations. He found out that:

  1. Release: Their discussions often were affected by their time within the release cycle. Early on in the cycle, developers were concerned about features, but as time went on, they were more concerned about the software being released, and were much more cautious about the change sets that were being applied.
  2. Perception: The perception around the change set was also important. If the developer was giving off a good impression, then colleagues would monitor them less. Alternatively, if a developer is giving off a poor impression, then their changes may be more heavily scrutinized.
  3. Risk Assessment: The developers were concerned about risk. High-risk change sets heavily encouraged developers to speak with each other. For example, if the change set was large, it was considered higher risk.
  4. Business Goals: The developers were often conscientious about code quality, but were always under pressure to release features and fix bugs. This leads to the phenomenon known as technical debt, where the developers know that the fix is inelegant and ugly, but are often unable to fix it next cycle because management pressure continues to push the developers to release more features.

These considerations may have implications on collaborative recommender tools because they suggest the contexts under which the recommender system may have to adapt itself toward.

Adrian’s posted his slides here so you can take a look!

ACM DL Author-ize serviceTo talk or not to talk: factors that influence communication around changesets

Adrian Schröter, Jorge Aranda, Daniela Damian, Irwin Kwan
CSCW ’12 Proceedings of the ACM 2012 conference on Computer Supported Cooperative Work, 2012