Tracking Productivity in .NET Coding / Team Explorer
In Visual Studio or asp.net is there a way to track a programmer's productivity -- lines of code created or altered and time spent in the project actively working/ debugging/ etc.?
We use Team Explorer for our code repository, so perhaps there is a way to use that.
I've looked at an example of a coding tracker and it seemed to only handle it locally for the local person to see. I'd like something perhaps handled in Team Explorer by the checked in developer.
I once worked for a company that had a tracker like that, but not visual studio related, and at the end of a quarter they would have a % productive and level of difficulty the person did in their coding.
Is there such a thing available anywhere for .NET programming?
thanks!
We use Team Explorer for our code repository, so perhaps there is a way to use that.
I've looked at an example of a coding tracker and it seemed to only handle it locally for the local person to see. I'd like something perhaps handled in Team Explorer by the checked in developer.
I once worked for a company that had a tracker like that, but not visual studio related, and at the end of a quarter they would have a % productive and level of difficulty the person did in their coding.
Is there such a thing available anywhere for .NET programming?
thanks!
ASKER
We do code reviews, so I don't see that's an issue.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Programming is a bit of art...i was reading this blog post Performance Improvements in .NET Core ...if you read it some contributors managed to squeeze amazing performance gains...most of them being just a few lines of code...so how would you "measure" someone that accomplished such a achievement ...these few lines could/should mean the world...but these don't come easy....maybe even years of experience is needed to accomplish something like that and there is no guarantee.
Using an automated system is like putting a metric of the art of DaVinci, Dali, Van Gogh ........
If you really want to measure programmers...then put challenges...put the bonus on the table and say " the objective is to make the application faster...or the objective is to make it stable....or... just find a valid objective"
Stop counting lines and start appreciating quality.
Using an automated system is like putting a metric of the art of DaVinci, Dali, Van Gogh ........
If you really want to measure programmers...then put challenges...put the bonus on the table and say " the objective is to make the application faster...or the objective is to make it stable....or... just find a valid objective"
Stop counting lines and start appreciating quality.
Just an additional two cents - if there is a concern that developers are slacking off (and that is why you're after the measurement), then it's normally best to address whatever the root cause is.
You should be able to assume that a team of developers are productive by default. If you suspect they are not, then:
1. Make sure your expectations are valid. Junior developers take a long time and produce so-so results. Intermediate developers often create large things faster than senior developers but have quality problems with their results (e.g. they don't take security into consideration). Senior developers will normally build complex things as fast as possible while delivering a good quality result.
Most developers overestimate their speed, so doubling a developer's time estimates can be a good practice (even if you don't tell them you've doubled their estimate).
However, not even the best of us can build Facebook in a week. So ensure you temper your expectations.
2. Make sure you don't have a poisonous team member. Every once in a blue moon, you'll get a person on the team that complains a lot - nothing is ever good enough and they will tear down others when their backs are turned (sometimes you'll get a brazen one that does it in front of you). These people are poisonous leaders and should be fired as soon as their character is positively identified. Any firing temporarily hurts morale but it's worse to let them stay.
3. Make sure you don't confuse breaks with slacking off. Some teams will play video games, some people just read news or browse social media. As long as the breaks are not excessive, they can often increase productivity and decrease burnout.
You should be able to assume that a team of developers are productive by default. If you suspect they are not, then:
1. Make sure your expectations are valid. Junior developers take a long time and produce so-so results. Intermediate developers often create large things faster than senior developers but have quality problems with their results (e.g. they don't take security into consideration). Senior developers will normally build complex things as fast as possible while delivering a good quality result.
Most developers overestimate their speed, so doubling a developer's time estimates can be a good practice (even if you don't tell them you've doubled their estimate).
However, not even the best of us can build Facebook in a week. So ensure you temper your expectations.
2. Make sure you don't have a poisonous team member. Every once in a blue moon, you'll get a person on the team that complains a lot - nothing is ever good enough and they will tear down others when their backs are turned (sometimes you'll get a brazen one that does it in front of you). These people are poisonous leaders and should be fired as soon as their character is positively identified. Any firing temporarily hurts morale but it's worse to let them stay.
3. Make sure you don't confuse breaks with slacking off. Some teams will play video games, some people just read news or browse social media. As long as the breaks are not excessive, they can often increase productivity and decrease burnout.
After reading your question I was super triggered to jump in (I am on a kind of a sabbatical from EE due to workload), and explain my view but gr8Gonzo has beautifully covered everything I would have said.
My request: Please don't go that route. Find other ways to motivate your team.
Regards,
Chinmay.
My request: Please don't go that route. Find other ways to motivate your team.
Regards,
Chinmay.
ASKER
>>The absolute biggest problem is that it creates incentive for developers to always write MORE code instead of EFFICIENT code.
If this were an issue with the tracking software, I wouldn't want to use it, because yes, I do get the quantity over quality problem if the software is written so poorly that it determines value based on number of lines of code.
However, the software used on this other application quantified the results by the efficiency of the code. For instance, other TPL programmers would write their code like this as an example:
<font style blah>Line of Code</font></br>
<font style blah>Line of Code</font></br>
<font style blah>Line of Code</font></br>
As opposed to
<font style blah>Line of Code</br>
Line of Code</br>
Line of Code</br>
</font>
The software could detect that the second solution was more efficient and graded accordingly. But the application I'm talking about was from the 80's and was in the phototypesetting industry.
It could detect if coders were calling methods or hard-coding every line with the values in the method.
Method MakeBoldAndItalic()
... code to make bold and italic
MakeBoldAndtalic()
Lines of Code
MakeRegular()
Lines of Code
MakeBoldAndtalic()
Lines of Code
I was looking to see if someone had developed something more robust than just a line counter.
If this were an issue with the tracking software, I wouldn't want to use it, because yes, I do get the quantity over quality problem if the software is written so poorly that it determines value based on number of lines of code.
However, the software used on this other application quantified the results by the efficiency of the code. For instance, other TPL programmers would write their code like this as an example:
<font style blah>Line of Code</font></br>
<font style blah>Line of Code</font></br>
<font style blah>Line of Code</font></br>
As opposed to
<font style blah>Line of Code</br>
Line of Code</br>
Line of Code</br>
</font>
The software could detect that the second solution was more efficient and graded accordingly. But the application I'm talking about was from the 80's and was in the phototypesetting industry.
It could detect if coders were calling methods or hard-coding every line with the values in the method.
Method MakeBoldAndItalic()
... code to make bold and italic
MakeBoldAndtalic()
Lines of Code
MakeRegular()
Lines of Code
MakeBoldAndtalic()
Lines of Code
I was looking to see if someone had developed something more robust than just a line counter.
ASKER
I can see where my initial question got off on this track that my interest is in counting lines of code, as a criteria for productivity, and that is not my intention.
>> lines of code created or altered and time spent in the project actively working/ debugging/ etc.?
My real intent is:
>> % productive and level of difficulty the person did in their coding.
However, lines of code isn't 100% detrimental to the results either.
For instance, I have one developer who only works on tasks where she is altering existing code and each task there is a one line change.
Versus a guy who writes entire web services.
If they take the same amount of time to complete their tickets, then there would be an issue.
Of course, human intervention must be involved, like, is she tracking down a bug, which requires research and debugging, as opposed to changing a value on a label.
I was just hoping there might be an intelligent solution out there that someone might be aware of. I appreciate all the feedback, but I'm not looking for a line counter.
I guess I'll just stick with the code reviews. I can check in their code with the team explorer and see what's changed and if it seems efficient and accurate. But it still doesn't tell me how much time they spent on it. So I have to go back to the ticketing system and see how much time they put in the work log.
thanks for your responses.
>> lines of code created or altered and time spent in the project actively working/ debugging/ etc.?
My real intent is:
>> % productive and level of difficulty the person did in their coding.
However, lines of code isn't 100% detrimental to the results either.
For instance, I have one developer who only works on tasks where she is altering existing code and each task there is a one line change.
Versus a guy who writes entire web services.
If they take the same amount of time to complete their tickets, then there would be an issue.
Of course, human intervention must be involved, like, is she tracking down a bug, which requires research and debugging, as opposed to changing a value on a label.
I was just hoping there might be an intelligent solution out there that someone might be aware of. I appreciate all the feedback, but I'm not looking for a line counter.
I guess I'll just stick with the code reviews. I can check in their code with the team explorer and see what's changed and if it seems efficient and accurate. But it still doesn't tell me how much time they spent on it. So I have to go back to the ticketing system and see how much time they put in the work log.
thanks for your responses.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
To my knowledge, there is nothing that would be able to -accurately- programmatically determine efficiency. There are many possible reasons a code might appear to be inefficient to an analyst (human or computer).
For example, let's say that you have this code:
An automated system would say, "Well, that could easily be consolidated/optimized into DataModel.FieldX += 2 without a problem!"
But let's say FieldX is a class property that raises an event whenever it's changed:
Event subscribers are very often added and removed all the time at runtime, so there'd be no way for anyone to realize that changing those 2 lines of code into 1 line would actually cause the event to only be fired once instead of twice (which could cause a catastrophic failure somewhere else).
Unfortunately, analyzing code is infinitely more complex than analyzing HTML styling, because whereas styling is simply an equation that produces one final visual result, code itself is an algorithm that can be implemented in many different and unexpected ways for good reasons.
For example, let's say that you have this code:
DataModel.FieldX++;
DataModel.FieldX++;An automated system would say, "Well, that could easily be consolidated/optimized into DataModel.FieldX += 2 without a problem!"
But let's say FieldX is a class property that raises an event whenever it's changed:
private int _FieldX = 0;
public int FieldX
{
get { return _FieldX; }
set
{
_FieldX = value;
RaiseEvent(FieldX);
}
}Event subscribers are very often added and removed all the time at runtime, so there'd be no way for anyone to realize that changing those 2 lines of code into 1 line would actually cause the event to only be fired once instead of twice (which could cause a catastrophic failure somewhere else).
Unfortunately, analyzing code is infinitely more complex than analyzing HTML styling, because whereas styling is simply an equation that produces one final visual result, code itself is an algorithm that can be implemented in many different and unexpected ways for good reasons.
I guess I'll just stick with the code reviews.I would strongly agree with that decision. Human analysis of code is almost always better than automated. Perhaps in the future, we'll have downloadable AI solutions that will start helping out with code reviews. However, even then, good architecture can sometimes play a bigger factor than efficient code, and that is again a human role to analyze.
ASKER
Thanks Chinmay!
I'll take a look!
I'll take a look!
It has begun :) https://docs.microsoft.com
Perhaps in the future, we'll have downloadable AI solutions that will start helping out with code reviews.
Let's take a small example...
You populate a DGV dynamically...you could type ..add each field one by one...so for a table with 50 fields (bad design) and you will have 50 lines of code...or you could create a loop that iterates the table fields and populate the DGV in a couple of lines...
Which programer is better?