oss dc 2010: software evolution and human resources: knowledge gap

8/8/2019 OSS DC 2010: Software Evolution and Human Resources: Knowledge gap

1/27

MotivationResearch Questions

MethodologyPreliminary Results

Further Work and Open Questions

Software Evolution and Human Resources.Knowledge Gap left by Developers due to Turnover

Daniel Izquierdo Cortazar

[email protected]/Libresoft, Universidad Rey Juan Carlos

Doctoral Consortium, OSS 2010, Notre Dame, USAMay, 30th 2010

Daniel Izquierdo Cortazar Software Evolution and Human Resources.
http://find/http://goback/


2/27




(cc) 2010 Daniel Izquierdo Cortazar.Some rights reserved. This document is distributed under the Creative

Commons Attribution-ShareAlike 2.5 licence, available inhttp://creativecommons.org/licenses/by-sa/2.5/



3/27




Table of contents

1 Motivation

2 Research Questions

3 Methodology

4 Preliminary Results

5 Further Work and Open Questions



4/27




Index

1 Motivation


3 Methodology




M i i


5/27




Introducing developers turnover

All the projects, even the most stable have to face developersturnover.

People tend to change their job after some years.

Project managers have to deal with these situations.

So, a new developer comes to fill that gap.


M ti ti


6/27





Thus, there is a natural regeneration of developers.Let us use junior for those who have just landed.

All of that experienced and knowledge about the project ismissed when seniors are gone.


Motivation


7/27





It is estimated in around 6 months the time to be productiveas the same level as seniors.

Even more if more sophisticated work is in progress.


Motivation


8/27





Thus, how to measure that knowledge gap left by developers?Source code lines / functions / files / modules.

We are dealing with the idea of orphaning.

And we are proposing a way to measure that knowledge gap.


Motivation


9/27




Previous definitions

Committer: Person who has the right to submit changes tothe source code management system (SCM).

Author: In some SCMs the real author could be specified(such as Git).

Non-active committer: That committer who left the project ina specific date.

Orphaned line: That line owned by a non-active committer.This line will remain until this is removed or modified.


Motivation


10/27




Intuition

Areas with high orphaning tend to remain in time.Bugs found in orphaned areas will take more time to be fixed.

Developers tend to work on their own source code.

Others...


Motivation


11/27

Research QuestionsMethodology

Preliminary ResultsFurther Work and Open Questions

Why could this be interesting?

Using the idea of orphaning, we could answer some questions:

Looking for abandoned areas in your project: full orphanedfiles/modules.How much orphaning is found in my project?: The higher theless knowledge over the source code.Check orphaned areas left by key developers: Then try to

re-collocate your best developers when some other leave.


Motivation


12/27



Index

1 Motivation


3 Methodology




Motivation


13/27



Some Initial Questions

So far, we have a new metric which provides information

about the quantity of orphaned code in your project.(Knowledge loss due to developers turnover).

In the following: so what?. This metric needs something moreto be validated.

This information should be matched/correlated with someother.


MotivationQ


14/27



Some Initial Questions

The first approach consists of matching orphaning and bugprediction/fixing process:

Is there any kind of relation between orphaning and bug fixing?Is there less maintenance in orphaned areas?Is it possible to have orphaning as a metric to measuremaintainability or code decay?Detecting areas with high orphaning, means lower maintenance

of them? (perhaps they are mature enough).


MotivationR h Q i


15/27



Hypothesis

General questions:The higher the regeneration of developers, the higher thenumber of orphaned lines.The lower the regeneration of developers, the lower thenumber of orphaned lines.


MotivationR s h Q sti s


16/27



Specific questions: (Real relation between orphaning and bugsactivity).

The knowledge gap tends to be absorbed by other active

developers.The larger areas with orphaned code, the ...:

... larger number of remaining open bug reports.

... longer time to fix those bugs.

... longer time to be picked up.

... more tossing changes found.

... more number of predicted bugs appear.




17/27



Index

1 Motivation


3 Methodology






18/27



CVSAnalY: CVS Log

[...]1.246 (pj 13-Nov-01): /* Optional arg STRING supplies menu name for the keymap1.246 (pj 13-Nov-01): in case you use it as a menu with x-popup-menu. */)1.246 (pj 13-Nov-01): (string)1.8 (rms 11-Sep-92): Lisp Object string;

1.8 (rms 11-Sep-92): {1.8 (rms 11-Sep-92): Lisp Object tail;1.8 (rms 11-Sep-92): if (!NILP (string))1.8 (rms 11-Sep-92): tail = Fcons (string, Qnil);1.8 (rms 11-Sep-92): else1.8 (rms 11-Sep-92): tail = Qnil;1.1 (jimb 06-May-91): return Fcons (Qkeymap,1.137 (rms 13-May-97): Fcons (Fmake char table (Qkeymap, Qnil), tail));1.1 (jimb 06-May-91): }

...




19/27



Orphaning

Projects which initially offer a Git repository (e.g.: the oneused by the Linux Kernel).

The differences between one version and next one areobtained and stored in a MySQL database.

If a developer leaves the project, her lines become orphaned.




20/27



Adding Bugs Information

There are two possibilities:Try to match orphaned lines with what we know (retrievingreal information from BTS).Try to predict bugs based on existing source code and changes.




21/27

QMethodology


Index

1 Motivation

2

Research Questions

3 Methodology






22/27



Case Studies: GIMP and Evolution

Both started at the same time (around 1998. At least usingthe Source Code Management system)

Both are included by default in the GNOME desktop (usingthe same process and release cycle)




23/27



Orphaned Lines vs Size

1998-02-28 2000-02-28 2002-03-28 2004-03-28 2006-03-28

Time

0

200000

400000

600000

800000

1000000

1200000

NumberofLines

Ev. Total Lines

Ev. Orph. LinesGIMP Total LinesGIMP Orph. Lines

Size an Orp ane Lines Evo ution



M h d l


24/27



Index

1 Motivation

2

Research Questions

3 Methodology





M th d l


25/27



Work in Progress

Still working on the tool to extract information: the examples

shown are based on an older version.

Also, understanding the bug prediction based on source code.

Improving the tool to extract information from BTS.

Analyzing results at file granularity.



Methodology


26/27



Open Questions

We still do not know what exactly means orphaning: matchingthat with bug prediction/bug fixing is expected to help.

Limitations:Mature areas could be wrong validated as orphaned areas.Communities such as PostgreSQL are quite restrictive: Thecommit rights are owned by few people.Working at the level of line could avoid from getting richer

information.Blank lines, changes such as spaces, adding licensesinformation, etc.



Methodology


27/27



Questions?

Thanks for your attendance!Questions?


oss dc 2010: software evolution and human resources: knowledge gap

Documents