Last night was one of those times when I couldn't sleep because my brain was busy inventing crackpot schemes. Maybe writing stuff down will help dispel the demons.
I was contemplating how long it had taken me to do the Text::VimColor release last night. It must have been 3–4 hours to sort everything out. Almost all of that time was spent tracking down bugs, writing and improving tests, writing the notes in the blog message, uploading to CPAN, and replying to the guy who submitted the patch. The actual changes to the software (the only changes that affect operation) are the removal of a single character from the Perl module, and the addition of 4 lines (plus explanatory comments) to the Vim script.
Aaron at work pointed me to a neat CPAN feature which can show a diff between the old and new versions.
So does it mean anything that software changes only slightly with time like this? Does it mean that the software has all the important features already, and only careful bug-fixing needs to be done to maintain it? If so, perhaps ‘hours-per-diff-line’ would be a useful code quality metric. But how would you measure it?
Timesheeting and CVS
Using CVS it's certainly possible to measure the amount of textual change in a new release of some software. Much of that isn't actually relevant to the quality of the code (like the tweaks I made in Text::VimColor to the copyright messages, or changes that just bump the version number). It might be a useful metric though.
How could the changes be correlated with time taken? At work we use a crufty timesheet tool I wrote in Perl and Gtk+. It maps time taken to RT ticket numbers. There wouldn't be any sane way of connecting that to CVS commits, which is OK because a lot of things we do don't affect CVS.
What if the timesheeting data was put directly into CVS? You could have some special syntax in commit messages for indicating estimated time taken. Combined with a script run at commit time to refuse commits without times indicated it might be a useful way of forcing hackers to document how much time they're spending (something I'm very bad at when I get stuck into some coding).
So maybe you'd see commit messages like this:
Fixed off-by-one error in foo counters [15mins]. Added test to catch same [7hours]. CVS: ------------------ CVS: Blah blah blah... CVS: ------------------
You could then work out things like the average time spent for each line of changes, or the time spent on a particular release. Maybe that could be useful; I don't know.