IWPSE/EVOL 2009 Talk

1. How Developer Communica2on
Frequency Relates to
Bug Introducing Changes
Roberto Abreu Rahul Premraj
VU University Amsterdam

2. Communica2on
Planning Priori2sing
Assigning Problem solving

3. Communica2on and Quality
IEEE SoDware, 2003
quality time
E d i t o r : J e f f r e y Vo a s I Cigital I voas@cigital.com
Do You Like Piña Coladas?
How Improved Communication Can
Improve Software Quality
Jane Huffman Hayes
I
n “The Piña Colada Song,” Rupert “Dean thinks he’s better than us. He looks
Holmes writes of a man who has be- down on us and doesn’t listen when we of-
come disgruntled with his “old lady” fer constructive suggestions for improving
but fails to tell her. Instead, he runs an the walkthrough process.” And his man-
ad in the personals searching for a ager? “Dean seems to be out to get the de-
woman who likes piña coladas and velopers. He’s not a team player and isn’t
long walks on the beach. He receives a re- helping us improve.”
ply from a mystery woman who This simple miscommunication leads to
shares his interests and wants to three dissatisfied groups all working toward
meet at “a bar called O’Mal- a common goal—the project’s success. We
ley’s.” He walks in and is sur- must find ways to talk to each other and
prised to see that his “old lovely communicate openly.
lady” has answered his ad.
So, what does Rupert Holmes’ Software communication
song have to do with software We seem to have fairly well-defined meth-
quality? A lot, I contend. Commu- ods for handling communication within soft-
nication, or rather lack thereof, ware. For example, design by contract,1 class
leads to tremendous problems in responsibility collaboration cards,2 and in-
the workplace and in software. variants all help ensure that classes, modules,
or components know what to expect of each
Lack of communication = other, what is required for the desired behav-
miscommunication ior or action, and how to tell if that behavior
Let’s examine a software quality scenario. has occurred. We understand some quality
Dean is unhappy in his position. He is the attributes—such as portability, interoper-

4. Communica2on and Quality
60
45
30
15
Communica2on Code quality
0

5. Communica2on and Quality
There is a rela2onship between communica2on frequency amongst
all developers and quality of contemporarily developed code.
There is a rela2onship between communica2on frequency amongst
key developers and quality of contemporarily developed code.
Communica2on frequency can poten2ally augment accuracy of
defect predic2on models.

6. Data Collec2on
Bug introducing changes
Communica2on data from mailing lists

7. Bug Introducing Changes
MSR Workshop 2005
When Do Changes Induce Fixes?
(On Fridays.)
´
Jacek Sliwerski Thomas Zimmermann Andreas Zeller
International Max Planck Research School Department of Computer Science
Jacek Sliwerski Max Planck Institute for Computer Science
Saarbrucken, Germany
¨
Saarland University
Saarbrucken, Germany
¨
sliwers@mpi-sb.mpg.de {tz, zeller}@acm.org
ABSTRACT Which change properties may lead to problems? We can inves-
As a software system evolves, programmers make changes that tigate which properties of a change correlate with inducing
sometimes cause problems. We analyze CVS archives for fix-in- fixes, for instance, changes made on a specific day or by a
ducing changes—changes that lead to problems, indicated by fixes. specific group of developers.
Thomas We show how to automatically locate fix-inducing changes by link-
ing a version archive (such as CVS) to a bug database (such as
How error-prone is my product? We can assign a metric to the
product—on average, how likely is it that a change induces a
Zimmermann BUGZILLA). In a first investigation of the MOZILLA and ECLIPSE
history, it turns out that fix-inducing changes show distinct patterns
later fix?
with respect to their size and the day of week they were applied. How can I filter out problematic changes? When extracting the
architecture via co-changes from a version archive, there is
Categories and Subject Descriptors no need to consider fix-inducing changes, as they get undone
later.
D.2.7 [Software Engineering]: Distribution, Maintenance, and
Enhancement—corrections, version control; D.2.8 [Metrics]: Com- Can I improve guidance along related changes? When using co-
plexity measures changes to guide programmers along related changes, we
would like to avoid fix-inducing changes in our suggestions.
General Terms This paper describes our first experiences with fix-inducing chang-
Andreas Zeller Management, Measurement es. We discuss how to extract data from version and bug archives
(Section 2), and how we link bug reports to changes (Section 3).

8. Bug Introducing Changes
Link version archive Iden2fying
and bug database revisions with bugs
CVS annotate
!"#$%&'()& Link (SVN blame)
*+,-./
What revision modified
each line of a file?
!"#$%&'()#*+%," Bug Database

9. Bug Introducing Changes
Link version archive Iden2fying
and bug database revisions with bugs
CVS annotate
!"#$%&'()& Link (SVN blame)
*+,-./
!"#$%$&'(
)*+ !"#$%&
!"#$%&'()#*+%," Bug Database

10. Bug Introducing Changes
‣ Collected bugs the Eclipse project from
November 4, 2001 to November 24, 2006.
‣ Filtered to only include bugs fixed in the
JDT project.
‣ Computed weekly counts of bugs
introduced using commit 2me stamps.

11. Communica2on Data
CONTACT LEGAL
HOME USERS MEMBERS COMMITTERS DOWNLOADS RESOURCES PROJECTS ABOUT US
Search A A
List archive of Jdt-core-dev Other Views
List Home List Home
Return to current month RSS Feed
for this list
Index by
2001 date
Index by
November December thread
Index of all
2002 Mailing
lists
January February March April May June July August September October
November December
2003
January February March April May June July August September October
November December
2004
January February March April May June July August September October
November December
2005
January February March April May June July August September October
November December

12. Communica2on Data
• Number of messages exchanged per week.
• Number of message threads started per
week.
• Dis2nct developers (from mul2ple aliases).

13. Iden2fying Developers
hbp://www.eclipse.org/projects/project_summary.php?projec2d=eclipse.jdt
Committers
• 380 dis2nct individuals
sub-projects: apt, core, debug, doc, ui
Active:
David Audel
Frederic Fusier
from 439 name‐email
Walter Harley
Kent Johnson pairs.
Markus Keller
• Not all are developers!
Dani Megert
Kim Moir
Michael Rennie
Srikanth Sankaran
Olivier Thomann
Curtis Windatt
• Selected 18 of 35 listed
Darin Wright
Participating:
commibers to match
Benno Baumgartner
Jerome Lanneluc
bug database 2me
Philippe Mulet
Inactive:
period.
Martin Aeschlimann
Dirk Baeumer
Kevin Barnes

14. Srikanth Sankaran
Olivier Thomann
Curtis Windatt
Iden2fying Developers
Darin Wright
Participating:
Benno Baumgartner
Jerome Lanneluc
Philippe Mulet
hbp://www.eclipse.org/projects/project_summary.php?projec2d=eclipse.jdt
Inactive:
Martin Aeschlimann
• 380 dis2nct individuals
Dirk Baeumer
Kevin Barnes
Maxime Daniel
Jim Des Rivieres
Sonia Dimitrov
from 439 name‐email
Erich Gamma
Kari Halsted
pairs.
Tom Hofmann (nee Eicher)
• Not all are developers!
Eric Jodet
Janek Lasocki-Biczysko
Susan McCourt
• Selected 18 of 35 listed
Lorne Parsons
Darin Swanson
Andre Weinand
John Wiegand
Mike Wilson
commibers to match
Theodora Yeung
Emeritus:
bug database 2me
Adam Kiezun
Kai-Uwe Maetzel
period.

15. Communica2on and Quality
There is a rela2onship between communica2on frequency
amongst all developers and contemporarily developer code.
There is a rela2onship between communica2on frequency
amongst key developers and contemporarily developer code.
Communica2on frequency can poten2ally augment
accuracy of defect predic2on models.

16. Communica2on vs. Bug
introducing changes

17. Communica2on vs. Bug
introducing changes
No. of bugs No. of messages
2.0 2.1
●
120
●
●
●●
Bug−Message Frequency / Week
100
●
●
●
●
●
● ●
●
80
● ●
●
● ●●● ● ●
● ●
●
● ●
60
●
● ●
●
● ●● ●
●
● ● ●
● ● ●
40
● ●
●● ● ● ●
●● ● ●
● ● ●
● ●
● ●
●
●● ● ● ● ●
20
●●
● ● ●
● ● ● ● ●●●
● ● ●
● ● ● ● ●
● ● ● ● ●
● ●
●● ●● ● ● ●● ● ● ● ● ●●●●
●● ●
●
● ● ●● ● ● ● ● ●
● ● ● ●●
● ● ● ●● ● ● ●
● ● ● ● ●● ●
● ● ● ●●
●●
● ●
● ● ●●
●
0
45−01 04−02 16−02 28−02 40−02 52−02 11−03

18. Communica2on vs. Bug
introducing changes
No. of bugs No. of messages
2.0 2.1 2.1.1 2.1.2 2.1.3 3.0 3.0.1 3.0.2 3.1 3.1.1 3.1.2 3
●
●
●
●●
●●
● ●
●
● ● ●
● ●
● ● ●
● ●●
● ● ●
● ●
● ●
● ●
● ● ● ●
● ● ●
●● ● ● ● ● ● ●
● ● ● ● ●
● ●
● ● ● ●
● ● ● ● ●
● ●
● ● ● ● ●
● ● ●
● ●● ● ● ● ● ●
● ● ●
● ●
● ●● ●● ● ● ● ●
●● ● ●
● ● ● ● ●
● ●
● ● ● ●● ● ● ● ●
●● ● ● ● ● ●
● ● ● ● ● ●
● ● ● ● ● ● ●
● ● ● ● ● ● ● ● ● ●
● ● ● ● ● ● ● ●
● ● ● ● ● ● ●
● ● ● ●
● ● ● ● ● ● ●
● ● ● ●● ● ● ● ● ● ● ●
● ●● ● ●
● ● ● ● ● ● ● ●
● ● ●
● ●
● ● ●
●●●
● ● ● ● ● ● ●
● ● ● ● ●● ●● ● ● ●
● ● ● ●
● ● ●
● ● ● ●● ● ●● ●● ●● ● ● ● ● ●
●● ● ● ●● ● ● ● ●● ● ●
●● ●● ● ● ● ● ●
● ●●
● ● ●
●
●● ● ● ● ● ● ●
● ●● ● ● ●●
● ● ● ●
● ●
●● ● ●
●
●
●●
●●● ● ●● ●● ● ●
● ● ● ●
● ●●
●
●●
● ● ● ● ●● ● ● ● ● ● ●● ● ●● ●●●●● ● ● ●● ● ● ● ● ●
●● ● ● ● ●
● ● ● ● ● ● ● ● ● ● ●● ● ●
● ● ● ● ●● ● ● ●
● ●● ●● ● ● ● ● ● ● ● ● ● ●● ●● ●●●● ●
● ●● ● ● ●●●●●
●
●●
● ●●
● ● ● ●
●● ● ●● ●
● ●
16−02 28−02 40−02 52−02 11−03 23−03 35−03 47−03 06−04 18−04 30−04 42−04 01−05 13−05 25−05 37−05 49−05 08−06 2
Week−Year

19. Communica2on vs. Bug
introducing changes
No. of bugs No. of messages
2.1.1 2.1.2 2.1.3 3.0 3.0.1 3.0.2 3.1 3.1.1 3.1.2 3.2
●●
● ●
● ● ●
●
● ●
●●
● ●
● ●
● ●
● ●
● ●
● ● ● ●
● ● ●
● ●
● ● ●
● ● ●
● ●
● ● ●
● ● ●
● ●● ● ● ● ● ●
● ● ●
●● ●● ● ● ● ●
● ●
● ● ● ● ● ●
● ●● ● ● ● ●
●● ● ● ● ● ●
● ● ● ●
● ● ● ● ● ●
● ● ● ● ● ● ● ● ● ● ●
● ● ● ● ● ● ●
● ● ● ● ● ●
● ● ● ●
● ● ● ● ● ●
●● ● ● ● ● ● ● ●
● ●● ● ●
● ● ● ● ● ● ● ● ●
●
● ●
● ●
● ●● ● ● ● ● ● ● ●●
●● ● ● ● ●
●● ● ●● ●● ●● ● ● ● ● ●
●● ● ●
●● ● ●●
●● ● ● ● ● ●
● ● ●●
● ● ● ●
●
●● ● ● ● ● ● ● ● ● ● ●
● ● ●●
● ● ● ● ●●● ● ●● ●● ● ● ● ●
● ●● ●● ●● ● ● ● ●●●● ●● ●
● ● ● ● ● ● ● ● ● ●● ● ●● ●●●●● ● ●
● ● ●
●●
● ●
● ● ● ●● ● ●
●● ● ●
● ● ● ●● ●
● ●● ● ● ●
● ● ● ● ●● ●●● ● ● ● ● ●● ●● ●●●● ●
● ●● ● ●● ●●●● ●●●●● ●●●●●●●●●●
●● ●● ●
● ●●
● ● ● ● ●
●● ● ●●
● ● ●● ●●● ● ●●●●●
1−03 23−03 35−03 47−03 06−04 18−04 30−04 42−04 01−05 13−05 25−05 37−05 49−05 08−06 20−06 32−06 44−06
Week−Year

20. Communica2on vs. Bug
introducing changes
• Correla2on of bug introducing changes and
messages per week: 0.47.
• Correla2on of bug introducing changes and
message threads per week: 0.45.
Posi2ve correla2on!!!

21. Communica2on and Quality
There is a rela2onship between communica2on frequency
amongst all developers and contemporarily developer code.
There is a rela2onship between communica2on frequency
amongst key developers and contemporarily developer code.
Communica2on frequency can poten2ally augment
accuracy of defect predic2on models.

22. Key Developers
Degree of centrality for
in‐degree out‐degree combined

23. Key Developers
!"&$
!#"$
!&#(
!'))
!"!*
!##$ !''(
!"&)
!""! !'#$
!#"( !%$#
!#''
!#$$
!%&# !""%
!#")

24. Key Developers
!"&$
!#"$
!&#(
!'))
!"!*
!##$ !''(
!"&)
!""! !'#$
!#"( !%$#
!#''
!#$$
!%&# !""%
!#")

25. Key Developers
Correla2on between communica2on frequency of
key developers and bug introducing changes ranged
from 0.06 to 0.16.

26. Communica2on and Quality
There is a rela2onship between communica2on frequency
amongst all developers and contemporarily developer code.
There is a rela2onship between communica2on frequency
amongst key developers and contemporarily developer code.
Communica2on frequency can poten2ally augment
accuracy of defect predic2on models.

27. Predic2ve Power
Files with >50
bug introducing changes Weeks with peaks
ted
jec
s in
Bug
Frequency
es
ag
ess
M
Time
39 files iden2fied 30 weeks found

28. Predic2ve Power
At least 10, and up to 17 of the 39 files were found to
be changed during the peaks.

29. Evolution in
Communication
Forming Storming Norming Performing
Developmental sequence in small groups. Psychology Bulle2n 63:384‐99, 1965.
Bruce Tuckman

30. Evolution in
Communication
Forming Storming Norming Performing
Do these paberns apply to FLOSS and how do they
relate to soDware quality?
Developmental sequence in small groups. Psychology Bulle2n 63:384‐99, 1965.
Bruce Tuckman

31. Conclusions
Peaks in communica2on can coincide with peaks in bug
introducing changes.
Communica2on frequency of en2re team, and not just
key developers, are indica2ve of defects introduced.
Communica2on frequency may poten2ally serve as
good indicator of files requiring thorough tes2ng.