[sraybell]

Very interesting approach. I still reel a bit from the thought of it. I presume this is your blog, so I'll try to be as courtesy as possible in my criticism. :-)

This invites all the same problems. There are management styles in play at some groups that seem to think that number of anything is a good measure. It's quantity over quality. If your next release has a "big feature", but a concise implementation, they may wonder why you only generated 20 code files instead of 200. And you're right back to square one again.

This may only apply to certain solutions, too. You mentioned python. I'm curious to see if the same could be applied to C#, or Java. Further, I've found that in some projects, we have Enums.cs, for instance, that contain all our enumeration types in that given Namespace or Pacakge (C# and Java respectively). Maybe they should get their own code file? Maybe not?

I think before you implement a system like this, you have to implement a good design structure. Otherwise, you have no solid adherence. You could easily bloat the count, or undercut it, as necessary.

Ultimately, we need a way to measure performance objectively, without meaningless numbers. I don't have a good solution, and I really don't know if I like yours or not. Hrm.

Thanks for the post, though! Will give me something to chew on while I run my scripts... :-)

[cool-RR]

I've been getting this criticism from several people already. You're basically saying that counting code files is still a very problematic measure of project progress. I agree. It's a terrible measure of project progress.

What I'm saying is, it's slightly less terrible than counting code lines, and it preserves the advantages of counting code lines.

[sraybell]

At least you're throwing ideas around. It's a problem that really does need a solution, and it would be nice to get more people thinking about this.

Maybe this is part of the macro problem of communicating to management that isn't necessarily technical (which is a problem in and of itself, because management at some level SHOULD be technical. I've found that if management isn't techy enough when their direct reports are highly technical, you get performance measurement disparity).