approach.tex

% !TEX root = thesis.tex
\startchapter{The Approach}
\label{chap:approach}
In this chapter we propose an approach to leverage the concept of socio-technical congruence to improve communication (social) interactions among developer to improve build success.
We base this approach on the findings presented in the previous two chapter that team communication (Chapter~\ref{chap:soc-net}) and socio-technical gaps (Chapter~\ref{chap:stc-net2}) have influence on build success.

\section{Approach to Leveraging Socio-Technical Congruence}
The main contribution of this thesis lies with the implicitly described approach to creating actionable knowledge from the socio-technical congruence concept as Cataldo et al~\cite{cataldo:cscw:2006} described it in their seminal paper.
Since the research questions we formulated for this thesis only implicitly describe the approach, it is necessary to describe the approach to wrest actionable insights from the concept of socio-technical congruence.

Our approach encompasses five steps:
\begin{enumerate}
\item Define scope of interest.
\item Define outcome metric.
\item Build social networks according to the scope in real time.
\item Build technical networks according to the scope in real time.
\item Generate actionable insights.
\end{enumerate}

\section{Define Scope} 
Each network, social, technical and thus socio-technical, needs to be built with a specific scope in mind.
For example, throughout this thesis we focus on software builds.
This focus defines the source and communication artifacts that are used to construct the social and technical networks.
In Chapter~\ref{chap:meth} Figure~\ref{fig:network} we showed how we conceptualized social networks and how defining software builds let us select communication artifacts for the construction of a social network for a specific build.

\section{Define Outcome}
In order to derive useful insights from the constructed networks the scope used to construct them needs to be complimented with an outcome metric.
For example, in this thesis we are interested in build success, a binary variable that states whether a build is of acceptable quality.
With an outcome measure at hand we can contrast networks to gain insights.
Note, that the outcome and scope are closely related as we need to attach the outcome to the social and technical network whose construction depend on the scope.

\section{Construct Social Networks}
After the defining the scope and outcome, the next step is to construct the socio-technical networks.
This involves identifying all communication channels that are programatically accessible in real time.
Some examples of communication channels that can be tapped into in real time are emails, forum style discussions, or text chats.
Gathering all to the selected scope relevant communication artifacts than yields the social network.
In Chapter~\ref{chap:meth} Figure~\ref{fig:network} shows a detailed  example on how we construct a social network given a build as the scope of interest using data from the Rational Team Concert development team.

\section{Construct Technical Networks}
To complement the social networks and thus create socio-technical networks we need to produce technical networks.
The main issues is not to rely on information that is only available after the work has been completed and been submitted to a version repository, but to gather information to construct networks in real time.
For instance, Blincoe et al~\cite{blincoe:cscw:2012} proposed to use Mylyn\footnote{\url{http://tasktop.com/mylyn/}} events to accomplish the extraction of interactions with source code in real time.
In Chapter~\ref{chap:actionable} we detail how we use Mylyn traces to gather information to construct technical networks.

With respect to software quality it suffices to analyze complete changes and give feedback once the implementation work has been submitted to a central code repository.
In this case the network construction we described in Chapter~\ref{chap:meth} is sufficient to later on generate actionable knowledge.

\section{Generate Insights}
In Chapter~\ref{chap:stc-net2} we showed that gaps in socio-technical networks influence build success.
We take this as starting point for generating insights by breaking down socio-technical networks into triples the consists of a developer pair together with how they are connected, which can be either through a technical dependencies, a social dependency, both, or none.

Since we are focusing on improving the social interactions we focus on identifying those gaps (unmet coordination needs) that are most likely to increase build success.
For this purpose we split those triples derived from all socio-technical networks into two groups, those triples that originate from a socio-technical network of a failed build and those that originate from a socio-technical network of a successful build.

For each triple we can now apply statistical tests to see if a given triple is more often observed with failed or successful builds.
Those that are statistically significant for failed builds should be broken by suggesting to developers to communicate.
To ensure not to worsen the odds of a successful build we contrast the developer pair forming the gap with the same pair being connected both technically and socially.

\section{Conclusion}
The approach we described builds on our work on software builds and the influence of communication and unmet coordination needs as shown in the previous two chapters.
Note that this approach can also be applied to identify those met coordination needs that warrant further examination, by applying the same insight generation to pairs of developer that are connected both through a technical and social dependency.

The following three chapters aim at identifying the usefulness of the approach we detailed in this chapter.
We start by first investigating whether we can using this approach generate recommendation that are statistically significant (Chapter~\ref{chap:stc-net}).
Following, we diverge from the path of exploring the validity of the recommendations and focus on whether developers are open to such recommendations (Chapter~\ref{chap:talk}).
Finally, in class room setting we explore whether we could generate recommendations that might have prevented builds from failing (Chapter~\ref{chap:actionable}).