The are a few kinds of contributions e.g:
- Analysis of problems and translation to UX, requirements
- The production of design
- The production of working code and unit tests
- Creation of integration and system tests
- Pairing up with another developer on his/her machine
- Guiding another developer or reviewing others' products
- Debugging bugs and fixing in any code (by any author)
Ideally, any developer should be able to get his hands dirty in any code, to get the work done - so measuring by metrics on area of code is wrong.
Measuring by lines of code is completely idiotic (sorry to have be the one to tell you this). See example here. The quality of the code matters - not the quantity. In fact shorter is often better.
Measuring by number checked-in components is wrong - doesn't account with non-coding work and pair programming (which happens all the time, even if not officially). Also this ignores quality.
The ultimate bottom line is team work, not the work of individuals.
The time spent guiding others is often more important than the time spent working alone.
If you reward individual performance you will be ruining the team work and making your projects fail in the long run. (See this link.)
What you should measure is things like (not a full list and not in any specific order):
- Research and Innovations - self learning, solving (design or code) problems using unique thinking, introducing others to new technologies and methods
- System vision (seeing bigger picture beyond single tasks)
- Quality of design (maintainability)
- Quality of code (readability, test coverage)
- Completion of personal commitments on time
- Responsibility - does the developer make sure outputs are usable and depended tasks aren't stuck and help others complete depended tasks when necessary
- Guidance - does developer help others when possible if they need help or to maintain quality of teams outputs
- Adaptability - willingness to consider changes and new ideas
- Does developer take on tasks upon himself beyond his personal responsibilities
- Communication - does developer communicate well with team
The above are important factors in deciding seniority, accomplishments, rewards and etc.
Team leaders should be chosen by team leading skills, not by coding skills. E.g:
- Project management
- Analysis
- System vision
- Guidance
- People skills
- Ability to listen to anyone
- Ability to drive others, whether subordinates, bosses or neither