
\section{Conclusion}

We have shown above that a repository containing just static code measures can be still be used
to infer interaction patterns amongst developers. Specifically, we studied the ``active'' classes,
that is, the classes where the developers spend much time interacting with each other's
design and implementation decisions. 
In \NSystems open-source Java systems, we found that defect predictors based on static code measures that 
model ``activity'' perform within 96\% of a theoretical upper bound. This upper bound was derived assuming
that the goal of the detectors was ``inspection optimization,'' that is, read the fewest lines of code to find the most defects.

There is another aspect of activity measures 
that recommends their use. In this paper, we show that  simple linear regression over these measures
works very well indeed. That is, the machinery required to convert these measures into defect predictors
is far  less complex than alternative approaches, such as:

\bi
\item Lessmann's  random forests and support-vector machines~\cite{lessmann09},
\item The many  methods explored by Khoshgoftaar~\cite{taghi05a,taghi05,taghi00a},
\item Defect prediction via multiple explanatory variables~\cite{Briand00a,Nagappan06a},
\item Our own defect predictors via feature selection~\cite{me07b}, instance selection~\cite{Turhan09a}, or 
novel learners built for particular tasks~\cite{me10d}.
\ei

The comparative simplicity of activity-based prediction, suggests that previous work~\cite{mccabe76,lessmann09,taghi05a,taghi05,taghi00a,Harrison98a, Briand99a,Briand00a,Nagappan06a}, including our own research~\cite{me07b,Turhan09a,me10d}, may have needlessly complicated a very simple concept, that is,
defects are introduced and discovered due to all the activity around a small number of most active classes.
