2. Software Dev. Practices
Segundo David Weiss, cada um faz
de um jeito.
“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
3. Software Dev. Practices
• Examples: How are the bugs verified? Code
inspection? Automated testing?
•
Formal verification?
Four eyes principle (verifier ≠ fixer)
• Test first
• Collective vs. strong ownership
• Coding standards
• Continuous integration
• Code documentation
Object-oriented programming vs
...
procedural
4. Software Quality
• Many definitions and metrics
• Design quality (coupling/cohesion)
• Code quality (Findbugs, Checkstyle)
• Functional quality (# of bugs)
Specify # of bugs:
- reported by users or devs?
- pre or post release?
- what criticality?
Also, there is much noise: people
don't report correctly the
criticality etc.
6. Observational study #1
• Nonconformance to four eyes principle
bug is not 100% fixed and needs to be
reopened? Fix on the fix: about 1-2% of the
bugs
• Data: bug reports on Eclipse’s Bugzilla
7. Alessandro. Quando o verifier
atua? So no final? QA?
Cristina. Os verifiers sao
developers? Sao core developers?
“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.”
http://wiki.eclipse.org/Development_Resources/HOWTO/Bugzilla_Use
8. Methods
• Selected only verified bugs with last
modification ≤ December, 2009.
¬reopened reopened
Eclipse/JDT
¬conform 6838 167
conform 9707 94
• Fisher’s exact test
9. 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?)
Maybe verification is being done
informally, and not being reported.
Bugs per LOC correlates with need to
• BIRT, EMF etc.
reopen bug?
How productivity affects quality? See
"assessing the state of sw dev in a
large enterprise", by Weiss, Mockus et
al., j. Emp. Sw. Eng. 2009
Present results to developers and see
what they have to say (focus on
valiation!)
11. Next: Context
This is a key concept.
What happens when there's
turnover on the core developer
team? Wrt productivity? Wrt
quality? David Weiss is
interested in seeing these
layouts.
Crowston & Howison (2005) - The social structure of free
and open source software development
14. Related work
• Collectivetoo many cooks? quality: enough
eyeballs or
ownership vs.
• 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)
15. Related work
• Coding conventions vs. quality:
• Butler2010: low quality identifiers low quality code
(Findbugs)
• Maruping2008: coding conventions improve software
quality
17. 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