\documentclass{acm_proc_article-sp}
\usepackage{url} 
\usepackage{graphicx} 
%\usepackage{subfig}
\usepackage{verbatim}
\usepackage{fancyvrb}
\usepackage{algorithm}
\usepackage{algorithmic}
\usepackage{placeins}
\usepackage{rotating}
%\usepackage{timtricks}
\usepackage{cite}

\begin{document}
\title{Experiences on Developer Participation and Effort Estimation}

\numberofauthors{3} 
\author{
\alignauthor
Ekrem Kocaguneli\\
       \affaddr{Lane Department of Computer Science and Electrical Engineering}\\
       \affaddr{West Virginia University}\\
       \affaddr{Morgantown, WV 26505, USA}\\
       \email{ekocagun@mix.wvu.edu}
% 2nd. author
\alignauthor
Bora Caglayan, Ayse Tosun\\
       \affaddr{Computer Engineering Department}\\
       \affaddr{Bogazici University}\\
       \affaddr{34342 Bebek, Istanbul, TURKEY}\\
       \email{bora.caglayan@boun.edu.tr, ayse.tosun@boun.edu.tr}
\alignauthor
Ayse Bener\\
       \affaddr{Ted Rogers School of Information Technology Management}\\
       \affaddr{Ryerson University}\\
       \affaddr{Toronto, CANADA}\\
       \email{ayse.bener@ryerson.ca}
}

\maketitle

\begin{abstract}
Software effort estimation is critical for resource
allocation and planning. 
Accurate estimates enable managers to distribute the workload among resources in a balanced manner. 
Organizations use different project management tools. However, the actual
workload of developers may be different from the values observed in such tools.
In this research, we provide a summary of our experiences regarding: a) effort estimation
activities, b) the developer workload distribution through churn data and c) a method of using churn data to track estimation process.
Our experience report depends on our collaborative work with our industry partners operating in various domains in Turkey. As a result, we observe that effort estimation is taken as an important topic. However, there is a large space for research to transfer the ad-hoc methods employed in industry to empirical ones. Interestingly, we observe that resource allocations based on initial estimates/plans do not conform to actual developer workloads. The common characteristic of developer contribution in different projects is: More than 80\% of edits in code are performed by a small number of developers.

\end{abstract}

% A category with the (minimum) three required fields
%\category{H.4}{Information Systems Applications}{Miscellaneous}
%A category including the fourth, optional field follows...
%\category{D.2.8}{Software Engineering}{Metrics}[complexity measures, performance measures]

%\terms{Theory}

%\keywords{ACM proceedings, \LaTeX, text tagging} % NOT required for Proceedings

\section{Introduction}
Being able to estimate the development effort of a software project accurately is an important indicator of mature software development processes.
Software effort estimation as well as resource planning and monitoring have been addressed in various contexts \cite{Boehm1981,Menzies2006, Kadoda2001, Kultur2008}.
A considerable number of the studies have used publicly available datasets in their experimental settings \cite{Menzies2006, Kadoda2001, Kultur2008}.
These results from publicly available datasets have provided a global picture of two issues: Software effort estimation and resource planning.

In our research, we report our experiences on two problems and provide a local picture from our industry collaborated projects with Turkish software industry.
In terms of effort estimation we provide details about the estimation models that are used in industrial settings.
As for the resource planning, we focus on programmer related activities and evaluate programmer contribution. 
Our research includes a wide range of companies from various domains: Banking, telecommunication as well as white good companies (embedded software development units).
When evaluating our results, we compare them to findings coming from open source projects.
Our purpose in that is to see whether there are any similarities between development activities in open source and closed company settings.

As a result of our research we have seen that the importance of software effort estimation and resource planning is well appreciated by the industry.
Software companies have their own ad-hoc models of dealing with these issues.
Developer activities and workload distribution are monitored and managed through third party or in-house developed project management tools.
As for effort estimation companies use 
\begin{itemize}
\item simple linear regression models, 
\item a form of expert-based estimation 
\item or a combination of the two.
\end{itemize}

The parameters of the regression models used for software effort estimation are determined by domain experts.
The weights assigned to these features so as to balance their relative importance are also identified by such experts.
However, as the characteristics of the projects change over time, some of factors that are important in software effort diminish and some new factors emerge.
In time, the models become less effective and even obsolete.
%One clarification we need to make is that, this way of model building is not a form of estimation through expert judgment.
%Estimation through expert judgment entails experts discussing and estimating the actual effort, whereas here experts only specify parameters of linear model \cite{Jorgensen2009}.

The monitoring of developer participation through project management tools is also controversial. 
Due to various concerns, all employees report their work hours in accordance with what was indicated by the project managers.
However, common intuition among employers is that some developers are believed to produce a greater portion of the work than the others.
The fact that certain developers producing more than the others is not a new concept.
Koch has conducted an extensive case study in which he has questioned the manpower distribution on open source projects~\cite{Koch2008}.
His conclusion was that in commercial and open source projects, the manpower distribution and corresponding production per developer in terms of static code attributes (e.g. lines of code, a.k.a. LOC) show different characteristics~\cite{Koch2008}.
We have seen similar results among the projects we have analyzed: Although workload is evenly distributed to developers, more than 80\% of all source code is produced by less than 20\% of the developers.

Our analysis is based on six projects coming from multiple software companies from different domains.
We also use these projects as the basis of software effort estimation related interviews.
For our analysis we use churn data and static code attributes. 
We analyze the churn data of all the projects in our research and give the necessary information regarding our analysis.
Since we collect our data from private companies, the proprietary rights is a big concern.
Hence, project and company names are kept anonymous.

The rest of the paper is organized as follows: In Section \ref{sec:background} we provide background information regarding software effort estimation and programmer participation.
In Section \ref{sec:data} the details of the data used in this research are discussed. 
Section \ref{sec:methodology} summarizes the adopted methodology and Section \ref{sec:results} discusses the results of our analysis. 
In Section \ref{sec:threats} the potential threats to the validity of this research are identified.
Finally we conclude our research in Section \ref{sec:conclusion}.

\section{Background}
\label{sec:background}

In this research we present our experiences in two parts.
The first part is about our observations that we elicited during various projects with the industry.
The second part concerns developer participation in software industry through churn analysis of various projects coming from different software companies in Turkey.
Therefore, in this section we provide some background information regarding these issues. 

We can categorize software effort estimation into two groups\cite{Shepperd2007}: Expert judgment-based techniques and model-based techniques.
The former approach entails experts discussing the effort of a new project and reaching a consensus on the estimated value, whereas the latter includes the use of a model that calculates the estimated value.
Model-based methods may also use expert opinion for parameter specification etc. however, the estimated value is indicated by the model itself and not the expert.

A very widely used technique in software effort estimation domain is expert judgment\cite{Jorgensen2004}.
The employment of expert judgment methods may be either through well defined methods like Delphi \cite{Boehm2000} or via ad-hoc methods like formal meetings between experts in an organization.
Although expert judgment methods are highly regarded in various settings, they have their own pitfalls.
To begin with, the application of expert judgment methods may create an atmosphere of competing interests.
The competing interests may be between different departments of an organization or between experts with different levels of expertise.
In the former case, the urgent needs of a particular department may result earlier deadlines for the project, which would in return affect the allocation of many resources and which may eventually challenge or even fail the project.
In the latter case, estimations of a senior expert may be more dominant to those of a junior expert regardless of their accuracy.
Secondly, human experts are evaluated as poor in terms of improving their estimation skills \cite{Jorgensen2009}.
Lastly, an organization willing to completely rely on expert judgment methods should keep in mind that lack of good experts will result in imprecise estimations.

Unlike expert judgment-based techniques, model-based methods rely on parametric or algorithmic models.
Parametric methods may adapt an expert-proposed model to local data.
Therefore, for the use of parametric methods collection of local data is a must.
One of the most widely known example to parametric methods is the COCOMO method proposed by Boehm \cite{Boehm1981}.
Algorithmic methods are useful when local data does not conform to the specifications of a parametric method.
Algorithmic methods employ various algorithms to evaluate local data, build a model and make an estimation.
Some well known examples to algorithmic methods are linear regression, case based reasoning systems, neural nets and model trees \cite{Menzies2006, Kadoda2001, Kultur2008, Kocaguneli2010}.
The methods are particularly useful when local data do not conform to the specifications of the expert's method.
These methods have been mostly aided with certain types of patches such as noise removal, instance selection, feature selection or by feature reduction.
Depending on the fundamental assumptions of each algorithm, a different patch can be selected.
%
%Certain organizations may choose to use an expert judgment and some other organizations may prefer to go with a model-based approach, or alternatively a combination of the two.
%Regardless of the adopted method, the goal of any estimation model is to attain high estimation accuracy values.


%\subsection{Type of Research}
%\label{subsec:case}
%According to two-dimension classification scheme proposed by Basili et. al. \cite{Basili1986}, our research falls into the class of blocked subject-project studies, which examine objects across a set of teams and a set of projects.
%To increase the granularity of this classification we can say that our research is a case study of effort estimation practices and developer contribution in Turkish software industry.
%Any study can be a formal experiment, a case study or a survey depending how many teams and how many projects are considered in this study and what the scale of the study is\cite{Kitchenham1995}.
%Due to the nature of formal experiments, they are limited in size and need careful control. 
%Case studies focus on what happens on a typical project and surveys on the other hand focus on what is happening over various types of projects.
%In our research we deal with different companies and different projects that were developed with different languages.
%Furthermore, we are more of an observer than an experimenter in our research. 
%This is due to the fact that rather than being able to experiment the response of projects as well as project teams in response to a changing factor, we merely observed the effort estimation practices and developer contributions across multiple projects and multiple companies. 
%From our reading of Kitchenham et. al. \cite{Kitchenham1995} our research conforms to the definition of a case study.
%
%Different case studies regarding both effort estimation practices and developer participations have been conducted in different settings.
%For example Jorgensen et. al. addresses the effort estimation practices and budget overruns in Norwegian software industry \cite{Molokken-Ostvold2004}.
%Koch questions effort modelling as well as developer participation over open source software projects in his extensive survey \cite{Koch2008}.
%Although similar case studies have been conducted by different researchers in different contexts previously, to the best of our knowledge there is no previous study evaluating the effort estimation practices and developer participation in the context of the Turkish software industry. 


\section{Data}
\label{sec:data}

In our research we analyze 6 different projects coming from different companies.
Both in terms of their development languages and in terms of their magnitude they are quite different from one another (see Figure \ref{fig:data}).
However, they were not selected randomly.
Ideally the suggested and practiced strategy for selecting projects is random sampling \cite{Kitchenham1995, Molokken-Ostvold2004}.
However, private organizations are not completely optimistic about sharing churn data and static code attribute information of all their projects.
Therefore, in our research we have asked them to provide us with representative projects of their software development activities.
This may have introduced a selection bias into our study and we will address this issue in Section \ref{sec:threats}. 

\begin{figure}[th!]
\centering
{\scriptsize  
\begin{tabular}{l|l|l|l|l}  
  \textbf{Project}&\textbf{\# developers}&\textbf{LOC}&\textbf{\# commits}&\textbf{Language}\\ \hline
  Project1 & 3 & 5,579 & 72 & Java\\
  Project2 & 110 & 623,173 & 12,384 & Java+JSP\\
  Project3 & 97 & 1,324,956 & 23,403 & PL/SQL\\
  Project4 & 7 & 7,034 & 212 & Java\\
  Project5 & 11 & 16,358 & 322 & Java+JSP\\
  Project6 & 19 & 68,550 & 2,387 & C
\end{tabular}}
\caption{6 projects coming from different organizations. Projects have a wide diversity in terms of their size, developers they use and the languages they were developed in.
}\label{fig:data}
\end{figure}

The project names and their particular characteristics are provided in Figure \ref{fig:data}.
Due to proprietary rights, we will name the projects and developers with numbers.
The properties of projects given in Figure \ref{fig:data} are number of developers in the project, total edited lines of code (\textit{total edited LOC = added LOC + deleted LOC}), total number of commits that were performed during the life-cycle of the project and the development language that was used to implement the project.
We see from Figure \ref{fig:data} that our sample set contains a wide variety of projects.
The smallest project in terms of size (Project1) employs only 3 developers and a total of 5579 LOC were edited.
The biggest project in terms of size (Project3) on the other hand employs 98 developers and includes a total of $1,324,956$ edited LOC.
Therefore, although we were unable to apply random selection in our research, the organization-selected representative projects show quite different characteristics.

\section{Methodology}
\label{sec:methodology}

%In this section we provide the details about the methodology we adopted and present our research questions that guided us in this research.

\subsection{Understanding the Estimation Models}
Our method for investigating the estimation models employed in organizations is to conduct various meetings with the domain experts.
The initial meetings consisted of half an hour to one hour individual interviews.
The aim of those meetings is to understand the company practices, tools and needs regarding effort estimation and planning activities.
We also wanted to interview a wide spectrum of positions in the company to get a grasp of different perspectives.
For example in one of the reported companies, we have interviewed 2 senior executives, 5 analysts, 3 architects and 2 developers. 
The domain experts to whom we have conducted this questionnaire are either directly responsible for software effort estimation related activities or they are working related to such activities (if organization has any).
During the interviews we based our discussion around some basic questions that targeted key aspects of the processes.
Some examples to these questions are:
\begin{itemize}
\item What is the expected outcome from an estimation model?
\item What sort of estimation practices do you perform for your projects?
\item What are the metrics that are collected from past projects? And how do you evaluate them?
\end{itemize}


\subsection{Metrics for Developer Participation}

To understand developer participation, we based our analysis on churn data.
For churn analysis, firstly the commit information of projects is extracted from source code control systems.
Since different companies use different types of source control systems, this process takes quite some time.
For each source control system, we wrote scripts to extract the commit information.

In this research we extracted the commit information associated with each developer for each project.
The commit information included added and deleted lines of code (LOC) for each developer in each project. 
The total number of added and deleted lines of code will be named as \textit{``edited lines of code''} from now on (see Equation \ref{EquationEditedLOC}).
In addition to edited lines of code, we recorded the total number of commits performed by each developer.

\begin{equation} \small
edited LOC = added LOC + deleted LOC
\label{EquationEditedLOC} 
\end{equation}

After extracting the commit information related to each developer, we used two metrics to measure developer participation in the projects.
The first metric we used is the percentage edited LOC ($Perc. LOC$) for each developer in a project.
Percentage edited LOC is the ratio of total edited LOC by a developer to the sum of edited LOC for all developers.
The calculation of $Perc. LOC$ for $developer_{i}$ is given in Equation \ref{EquationPercLOC}, where $n$ corresponds to the total number of developers.

\begin{equation} \small
Perc. LOC = \frac{editedLOC_{developer_{i}} * 100}{\sum_{j=1}^n editedLOC_{developer_{j}}}
\label{EquationPercLOC} 
\end{equation}

The second metric we used is the percentage of commits ($Perc. Commit$) performed by each developer during the development of a software project.
Calculation of $Perc. Commit$ is similar to that of $Perc. LOC$.
$Perc. Commit$ is the ratio of total number of commits performed by a single developer to the number of commits that were conducted by all the developers who worked in this project.
The calculation of $Perc. Commit$ is given in Equation \ref{EquationPercCommit}, where $n$ is the total number of developers in that project.

\begin{equation} \small
Perc. Commit = \frac{totalCommits_{developer_{i}} * 100}{\sum_{j=1}^n totalCommits_{developer_{j}}}
\label{EquationPercCommit} 
\end{equation}

\section{Results}
\label{sec:results}

Previously it was reported by Lederer et. al. in their survey that the software managers puts a high importance on the necessity of software effort estimation: On a scale from 1 (min) to 5 (max), the average importance attributed to effort estimation practice was $4.7$ \cite{Lederer1993}.
Our experiences from the companies we investigated are quite similar, i.e. all the managers share the idea that estimation and planning activities are essential.
However, rather than asking the importance attributed to software effort estimation, we asked whether the company conducts ``any'' estimation related activity or employs an estimation model at all.


All of the $6$ companies we questioned perform software estimation related activities.
Therefore, we can say that effort estimation practices are employed by all the companies we worked with, but the level of employment differs greatly from one company to the other.
Some companies have initiated projects for developing their own expert-based algorithmic model, whereas some companies suffice with formal or informal meetings among domain experts. 
2 of the companies employs a linear regression based model, in which attributes and the weights related to these attributes are defined by domain experts (the explicit cases).
One of these two companies have recently switched to a machine learning based estimation method.
The other companies employs expert judgment in their estimation activities.
However, they do not strictly follow a Delphi like expert judgment estimation method.
Instead they follow their ad-hoc processes that entails a number of meetings between domain experts for discussing the cost of a project. 
So, among the 6 companies of this research the mostly used estimation method is expert judgment.
That is probably due to the fact that it is a method that requires the least effort to adopt.
However, since the companies do not record the initial expert estimates of a project it is almost impossible to track the efficiency of this method.
Although being the minority case, two companies use an algorithmic model and only of these two companies have undergone the effort of developing a complex estimation model that employs machine learning algorithms.

\begin{figure}[th!]
\begin{center}
\includegraphics[width=0.48\textwidth]{project1.png}
\end{center}
\caption{The $Perc. LOC$ and $Perc. Commit$ information for Project1. Developer 1 is responsible for more than 80\% of the whole edited LOC.}
\label{fig:project1}
\end{figure}

After initial estimates of software effort, each company plans the allocation of their resources.
For that purpose the companies use various project management tools.
Some of the companies prefer their in-house developed project management tools, whereas some prefer to use open source or commercial tools.
From our interviews with domain experts, it is our understanding that managers try to distribute the total effort evenly to employees working in particular projects.
Keeping track of planned efforts is again performed on the project management tools.
Each employee to whom a task is assigned and a certain hours of effort is allocated is responsible to record the actually performed effort into the management tool.
However, the consensus among the domain experts from different companies is that the actual effort values entered into the tool are nothing but a confirmation of the planned values.
Therefore, the virtually even allocation of resources on the project management tools may be misleading.
In that case using churn data can be helpful to get a better picture of actual effort spent by developers.
On the other hand, none of the companies we have conducted this such an analysis of churn data for observing the participation of developers to the project.

For each project in these companies, we extracted churn data from their source control system and analyzed the developer contribution.
We have seen that a big portion of the whole development activity is performed by a very limited number of developers.
So our understanding is that the reflection of  estimation and planning activities on the actual values regarding the developer participation is relatively weak.
In other words, the effort of managers to evenly distribute the development effort among developers does not effectively find place in actual development environment.
In the next paragraphs, we will evaluate the results for each project separately.

\begin{figure}[th!]
\begin{center}
\includegraphics[width=0.8\textwidth, angle=90]{project2.png}
\end{center}
\caption{Project2 has the highest number of developers employed. Only 8 developers contribute more than 2\% to the project. The participation of more than half of the developers is less than 1\%.}
\label{fig:project2}
\end{figure}

In Figure \ref{fig:project1} we see the $Perc. LOC$ and $Perc. Commit$ information regarding Project1.
The x-axis corresponds to different developers whereas the y-axis is the percentage value associated with $Perc. LOC$ and $Perc. Commit$. 
Project1 is the smallest project among 6 projects in terms of size as well as in terms of employed developers.
We can see that the majority of the edited LOC in context of this project was developed by a single developer.
Developer 1 has edited more than 80\% of the total edited LOC.
The difference between developers participation in terms of $Perc. Commit$ metric becomes less.
However, this may be due to the fact that Developer 1 prefers to commit less often and the other two developers prefer to commit their changes more often.
The obvious way to understand the truth behind this assumption is to go back and talk with associated developers.
However, due to confidentiality reasons the developer names are kept hidden and backtracking this information becomes virtually impossible.


Figure \ref{fig:project2} provides the $Perc. LOC$ and $Perc. Commit$ values of Project2.
Project2 has the highest number of developers employed.
A total of 110 developers have contributed to this project during its development life-cycle.
The difference between developer contribution in Project2 is less than that of Project1.
However, this may be due to the effect of distributing a value of 100\% to 110 developers.
We see in Figure \ref{fig:project2} that after 8 developers, the contribution of individual developers goes below 2\%.
Furthermore, we can see from Figure \ref{fig:project2} that the contribution of more than half of the developers is less than 1\%.

\begin{figure}[b!]
\begin{center}
\includegraphics[width=0.9\textwidth, angle=90]{project3.png}
\end{center}
\caption{Project3 has 97 developers participating in the development activity. Majority of the developers have limited contribution. After developer 31, the participation of developers is less than 1\%.}
\label{fig:project3}
\end{figure} 

In Figure \ref{fig:project3} we see the $Perc. LOC$ and $Perc. Commit$ values of Project3.
Project3 is another densely populated project with 97 developers in total.
The behavior of developer contribution of Project3 is similar to that of Project2, i.e. only a small group of developers have a contribution of more than 2\% and a large number of developers (after developer 31) is responsible for less than 1\% of the total edited LOC. 
We also observe from Figure \ref{fig:project3} that the behaviour of $Perc. LOC$ is very similar to that of $Perc. Commit$.
Although there are some irregularities between the two lines, this may be due to different commit habits of individual developers. 

\begin{figure}[th!]
\begin{center}
\includegraphics[width=0.48\textwidth]{project4.png}
\end{center}
\caption{Project4 $Perc. LOC$ and $Perc. Commit$ information. Developer 1 and developer 2 have more than 80\% of the $Perc. LOC$ and the rest is shared by other 5 developers.}
\label{fig:project4}
\end{figure}

Figure \ref{fig:project4} summarizes the developer contribution of Project4.
Project4 is a relatively small project when compared to Project2 and Project3.
The contribution pattern among 7 developers employed in Project4 is similar to previous projects.
Only two developers account for more than 80\% of the whole edits and the remaining 5 developers account for less than 20\% of the edits.
Furthermore, like previous projects the $Perc. LOC$ and $Perc. Commit$ lines go hand in hand in Project4 as well.



\begin{figure}[th!]
\begin{center}
\includegraphics[width=0.48\textwidth]{project5.png}
\end{center}
\caption{$Perc. LOC$ and $Perc. Commit$ values of Project5. Similar trend of previous projects continues here. The first three developers account for more than 80\% of all edited LOC.}
\label{fig:project5}
\end{figure}

$Perc. LOC$ and $Perc. Commit$ information associated with Project5 are given in Figure \ref{fig:project5}.
Project5 has 11 developers employed in the development phase.
Among 11 developers the first three developers edit more than 80\% of all the edited LOC.
With developer 5 the contribution of developers in terms of $Perc. LOC$ goes below 5\% per developer.
One suspicious point in Figure \ref{fig:project5} is that there is a considerable difference between $Perc. LOC$ and $Perc. Commit$ values of Developer 1, who is the top developer.
The likely explanation to that case could be that Developer 1 was reviewing the code of other programmers and some of the developers were committing through Developer 1. 
Although this scenario is very likely in open source communities, this is not the case for this particular company and project.
After our inquiry with the company, we have learned that such a review and commit scenario does not exist for Project5.


\begin{figure}[th!]
\begin{center}
\includegraphics[width=0.48\textwidth]{project6.png}
\end{center}
\caption{Project6 $Perc. LOC$ and $Perc. Commit$ values. Out of 19 developers, the first 2 developers account for more than 50\% of the total edited LOC.}
\label{fig:project6}
\end{figure}


The last project in our research is Project6. 
Figure \ref{fig:project6} provides the $Perc. LOC$ and $Perc. Commit$ information of Project6.
In Project6 a total of 19 developers are employed.
Among 19 developers the first two developers alone have the total of more than 50\% of $Perc. LOC$.
Starting with Developer 5, the individual participation of developers fall below 5\% in terms of $Perc. LOC$. 
Furthermore, as in the case of all the previous projects the $Perc. Commit$ line in Figure \ref{fig:project6} behaves very similar to the line of $Perc. LOC$.


\section{Threats to Validity}
\label{sec:threats}
The most obvious threat to our research is the selection process of the projects.
Unlike widely used method of random selection of projects, our projects are selected by the experts of the organizations.
Expert selection is based on the fact that projects shall be representative of the company.
%When considering the wide range of projects in our research we can consider the dataset as representative of the organizations.
However, it cannot be proven that there is no selection bias coming from domain experts.

The number of projects evaluated may be considered as another threat to validity.
We acknowledge the fact that only six projects can be viewed limiting for this research.
%In addition, those projects were selected by domain experts, which also limits the validity of the findings.
%It would have been much better, if we could have used many more projects and if we have selected those projects randomly without human intervention.
However, the data shared by the companies (detailed project plans and individual employee performance) is viewed very sensitive and confidential by managers.
Therefore, although we forced our chances to get as many projects as we can we are bound to decisions made by company managements.
Furthermore, when we share our experiences and analysis with the domain experts, the consensus was that the trend we have seen in the representative projects can be generalized to a majority of the projects developed in these companies.

Another threat is the selected metrics to evaluate the developer participation.
Churn data stored in source control systems of open source projects and private organizations have some characteristic similarities.
%The use of $Perc. LOC$ and $Perc. Commit$ may be questionable.
Furthermore, edited LOC and commit count are successfully used in the studies concerning open source projects \cite{Koch2008, Caglayan2009}, so we also based our metrics on edited LOC and commit count as well.

Final threat to validity of our results is the complexity of the code that is committed by a developer.
In other words, the differences between developers in terms of $Perc. LOC$ can be due to the fact that some developers may be working on more complex parts of the software, hence being able to produce less LOC.
Unfortunately we were able to get the source code of only a single project to analyze the complexity of committed code.
Depending on our analysis we did not see such an effect.
The average complexity of the committed code by each developer was more or less the same.
Of course we cannot generalize our finding to all 6 projects.
However, this may be a hint that code complexity is not a strong validity threat for this research.


\section{Conclusion}
\label{sec:conclusion}

In this research we observed the effort estimation and its use in planning activities in the local software companies in Turkey.
We also addressed the implications of estimation and planning activities on developer contribution in software development.
Our data in this research included 6 representative projects coming from different companies that specialize in different domains.
Our analysis concerning these 6 projects were performed in two phases.
For effort estimation activities, we conducted personal meetings with domain experts to gain an insight into their estimation and planning processes.
For the developer contribution analysis on the other hand, we extracted churn data from source control systems and derived our metrics from the extracted churn data.


One implication of our study is that software industry is well aware of the software effort estimation concept and appreciates its importance.
All companies in our research implicitly or explicitly employ certain estimation methods.
However, estimation practices are mostly far from having a scientific basis.
Rather than following state-of-the-art effort estimation methodologies, organizations suffice with ad-hoc processes.
Among the companies we worked with, only one company had a solid machine learning based effort estimation model that was developed and implemented by our research team. 
%However, this is not a particular situation to Turkish software industry.
%It is a known fact that industry practices are usually more simplistic than the methods suggested in the literature.

Another implication of our research is about developer participation.
The workload distribution that is being tracked by managers through project management tools does not reflect the actual participation of developers.
In all 6 projects we analyzed, the majority of the edited LOC is committed by a very limited number of developers.
The fact that most of the code is developed by a limited number of developers is previously reported in open source domain \cite{Koch2008, Caglayan2009, Crowston2006,Robles2004}.
Skewed effort distribution was studied in multiple projects and it was observed that \%90 of the churn were done by the \%20 of the developers \cite{Koch2008} in an open source setting.
Although software development in a private organization has its similarities as well as dissimilarities in comparison to an open source environment, they share the common property of developer participation characteristic.

\section{Acknowledgment}
This research is supported in part by Turkish State Planning Organization (DPT) under project number 2007K120610. 

\bibliographystyle{abbrv}
\bibliography{myref}  

\end{document}
