Impact of Software Development Practices on

Software QualityRodrigo Rocha G. e Souza <rodrigorgs@gmail.com>

2011-07-09

Software Dev. Practices

“Practices are contained, repeatable, and transferable techniques used to improve some aspect of the performance of a software organization that is pertinent to the creation of its products.”Jorge Aranda (2010) - A Theory of Shared Understanding for Software Organizations [PhD Thesis], p. 123

Software Dev. Practices

• Examples:

• Four eyes principle (verifier ≠ fixer)

• Test first

• Collective vs. strong ownership

• Coding standards

• Continuous integration

• Code documentation ...

Software Quality

• Many definitions and metrics

• Design quality (coupling/cohesion)

• Code quality (Findbugs, Checkstyle)

• Functional quality (# of bugs)

Do practices impact quality? What practices?

In what contexts?

Observational study #1

• Nonconformance to four eyes principle ⇒

bug is not 100% fixed and needs to be reopened?

• Data: bug reports on Eclipse’s Bugzilla

http://wiki.eclipse.org/Development_Resources/HOWTO/Bugzilla_Use

“It is important that the verifier be a different person than the fixer because the fixer is too close to the code and thus may not be as diligent at testing the corner cases.”

Methods

• Selected only verified bugs with last modification ≤ December, 2009.

Eclipse/JDT ¬reopened reopened

¬conform 6838 167

conform 9707 94

• Fisher’s exact test

Results

• In some subprojects, bugs verified by the fixer were more likely to be reopened.

• 5x more likely on Eclipse/JDT

• 2.5x more likely on Eclipse/Platform

• In some subprojects, the difference was not statistically significant. (why?)

• BIRT, EMF etc.

Next

• context

• other projects

• other practices

Next: Context

Crowston & Howison (2005) - The social structure of free and open source software development

Next: Context

Philippe Kruchten (2010) - Contextualizing Agile Software Development

Next: other projects

• Available data:

• Eclipse

• Netbeans

• Firefox

• Chrome

Related work

• Collective ownership vs. quality: enough eyeballs or too many cooks?

• Bird2010: high ownership and few minor contributors ⇒

less defects (mostly in commercial projects)

• Rahman2011: “implicated” code* more often associated with a single developer’s contribution. Experience in the modified files is more important than general experience. (context: FOSS)* Code that was changed in a bug fix.

• Maruping2008: collective ownership improves software quality (in low expertise teams)

Related work

• Coding conventions vs. quality:

• Butler2010: low quality identifiers ⇒ low quality code

(Findbugs)

• Maruping2008: coding conventions improve software quality

Related work

• Process mining

• Cook1998

• Poncin2011

References

• Bird2010 - An Analysis of the Effect of Code Ownership on Software Quality across Windows, Eclipse, and Firefox

• Rahman2011 - Ownership, Experience and Defects- A fine-grained study of Authorship

• Maruping2008 - Role of collective ownership and coding standards in coordinating expertise in software project teams-annotated

• Butler2010 - Exploring the Influence of Identifier Names on Code Quality_ an empirical study

• Cook1998 - Discovering models of software processes from event-based data-annotated

• Poncin2011 - Process mining software repositories