Link Details

Ridiculous.

That would define the know-how in terms of how may different files i touched and how many lines i have touched? I'll fire that code beautifier every week then :)

Here is my recommended tool for determining which developers are key to your project. Its called "Asking them". Periodically ask your developers what parts of the project they are comfortable with. Ask them who they go to for help. Ask them who they consider essential to the project's success.

"I'll fire that code beautifier every week then :)"

code beautifier would not work ;) our algorithms can identify those cases and therefore not include those in your know-how metric

Would they catch a simple name-refactoring? Changing a variable name? Changing a method name? Changing a class name?

I can't argue that we can handle all the cases. And those you mentioned we can't identify right now. But we improve our algorithms daily - Москва не сразу строилась :)

I'm just a little concerned about directly relating lines of code to the know-how. Not only can it be easily gamed, but it also leaves out quite a few key factors. What if i changed one line of code, but had to look at 20 files to understand the bug? This has happened to me a few times. What if i'm the technical designer and planned the entire thing (classes, methods, public APIs, rough implementation details)? Now i'm handing that to the team members to implement (and eventually commit to source repository, which i guess is the only place you're looking at). And what about pair programming? Two people look at the code, only one is checking in (and in some cases it would be the junior person at the keyboard and the senior person as the "driver").

"What if i changed one line of code, but had to look at 20 files to understand the bug?"

Indeed, the case described will not add a know-how in those 20 files. But that is correct, just looking at the file doesn't add you a lot of knowledge. And also, all software projects have a history. And you usually contribute several times to components you have the real know-how. So it is more a theoretical problem.

"What if i'm the technical designer and planned the entire thing (classes, methods, public APIs, rough implementation details)? Now i'm handing that to the team members to implement (and eventually commit to source repository, which i guess is the only place you're looking at)."

Know-how metric is to evaluate programmers, but not technical designers ;)
From my experience, when you start doing technical design only, you actually loose true hands-on experience and you become much less efficient in coding than those who write the code. Sure, you can be great high-level architect the same time. But then know-how metric for architects should be different.

"And what about pair programming?"

Yes, pair programming is interesting case. Idea to solve this issue, is by evaluating the metrics for the pair of developers :) . If there is any research group interested to do the case-study on that, feel free to contact us.