Re: [Statcvs-users] Paper on performance indicators in CVS repositories

[Richard C. <ri...@cy...>]

James,

On 18 Oct 2005, at 07:07, James Ring wrote:
> In the case of my final year university group project, the  
> lecturers are
> explicitly basing some of our assessment on the number of lines  
> contributed
> to CVS. I think that this is a sorry situation, given how poorly a  
> simple
> line count can represent somebody's input to a software engineering  
> project.

True. In the words of Bill Gates: Measuring programming progress by  
lines of code is like measuring aircraft building progress by weight.  
(I love this quote. You teachers would probably hate it ;-)


>> Link and some commentary on my weblog:
>> http://dowhatimean.net/2005/10/cvs-and-performance
>
> You mention that the lack of correlation between code metrics and  
> access
> patterns does not bode well for StatCVS. I don't think that it's
> necessarily a bad thing... Finding correlations between student grades
> and CVS activity is only one possible application
> for a good tool such as StatCVS.
>
> For example, in an industry project, the project manager may use a  
> whole
> bunch of statistics from various sources (including, but not  
> limited to,
> StatCVS) to evaluate the health and progress of their project.
>
> I guess what I'm trying to say is that by not providing more  
> metrics, we'll
> never see if any interesting correlations come up in unexpected  
> places.
>
> I'd certainly like to see some sort of Java code metrics as an "add- 
> on"
> for StatCVS, like the ability to measure (for example) method fan-in
> and fan-out in a Java project over time.

That would certainly be interesting, but there are two issues: 1)  
It's programming language dependent, which limits the target  
audience. 2) I can't see how to present this in an end user  
application. If we have a graph of method fan-in over time, I can see  
everybody going: "OK, so method fan-in has risen 30% over the last  
half year. Now is this good or bad?"

Richard


>
> The more stats, the merrier!
>
>
>> Best,
>> Richard
>>
>>
>
> Thanks,
> James
> -- 
> James Ring
>
>
>