Re: CVS and assesment

[Todd Denniston]

Thomas Tuft Muller wrote:
> 
> Todd Denniston wrote:
> 
> | I will however only give you the first line of such an
> | abomination that I have
> | been forced to live under:
> | cvs checkout -r HEAD -p $MODULE_NAME 2>/dev/null > $TMP_FILE2
> |
> | It's up to you to determine what kind of tyrannical analysis of
> | $TMP_FILE2 you
> | want to do with a FORTRAN program or perl script.
> 
> I fail to see why some(?) programmers are so reluctant to have their work
> analyzed and assessed. I'm a programmer myself, and I'm pretty sure that
> such a tool could benefit good programmers and maybe expose the bad seeds.
> Sound competion with fellow workers has never hurt anyone. I mean, a lot of
> employees out there have their work scrutinized and analyzed every day. Why
> should we be any different? Do we think we are irreplaceable no matter how
> much and what we actually do?
> 
> Programmers constitute a very arcane society and I think a lot of companies
> would like to be able to assess the quality of the Software Development
> department as well as they do for other departments. The problem is that
> "Software Quality" is an understatement in a world where extreme programming
> emerges as the prevalent development process. I think (good) programmers
> should be the first in line for deploying tools and processes for assessing
> their own work. Or are we too scared?

Only that we will be dealing with _another_ lazy boss who thinks just because
the tool indicates it is bad that it is.  These bosses are lazy because they do
not want to spend the time to have the programmers understand each others code
(peer review), and manage the fact that you will occasionally get a programmer
who is a back biter.

> 
> --
> 
> Thomas
> 

> I wonder if anybody have som experience with using CVS to follow up
> work-quality, project progress, individual measurement of work amount done
> over specific periods of time etc, etc. I imagine a scenario where each
> programmer is forced to check in once a week (preferrably with a specific
> tag indicating that the files are possibly untested/uncompilable).

hey, if the problem is small enough to solve in a week fine, however being
forced to checkin code which may not be functional or may not be fully
functional and then justify it, is only disruptive.

> Proper
> scripts could analyze the code regarding inter alia number of
> lines/words/bytes,

Again only a manager who is lame brained (wait how many does than not describe)
would still look at lines/words/bytes instead of functionality added or bugs
squashed.

> commenting, commenting rules, coding-rules, 

Ok, this might make some sense, however peer review is better from the
perspective of most rules have some point where they break down in the
readability/maintainability of the code.

> class
> cohesion, method-length, class-length, parameter names, variable names, etc,
> etc. 

again, peer review still does this better and saner.

>In addition the scripts should also take into account the state of the
> archive last time the scripts were run, and analyze/provide statistics about
> the change.

Unless your scripts can check all of the functionality of the system or show
you which trouble reports were fixed, it is pretty useless.  Better to check
the commit comments and make the programmer put in something useful that can be
tracked back to the requirements or trouble reports, so you can use something
like http://www.red-bean.com/cvs2cl/ to generate your reports to your boss.

> 
> Combined with a weekly/monthly submitted timeplan from the programmers, this
> could be a valuable tool for managers to see the overall as well as
> individual progress/quality.
> 

If your programmers are any good the things you mention above will not be
valuable for measuring progress, you should be measuring system functionality
and how well the programmers estimate time for adding functionality and fixing
bugs.

---------------
I suppose that we should take any further discussion of this off list.

-- 
______________________________________________________________________________
Todd Denniston, Code 6067, NSWC Crane mailto:address@hidden
I'd crawl over an acre of 'Visual This++' and 'Integrated Development
That' to get to gcc, Emacs, and gdb.  Thank you.
        -- Vance Petree, Virginia Power

The opinions expressed here are not sanctioned by and do not necessarily 
represent those of my employer.