1

Trying to keep track of progress and establish company-wide benchmarks. I understand that each language is different, but are there general benchmarks for these sorts of things?

Developers probably shouldn't make a TON of changes at once and do it all as one commit. But they probably shouldn't commit at every line change.

Any thoughts on performance standards?

Shamoon
  • 41,293
  • 91
  • 306
  • 570
  • Can you elaborate on what exactly you want to [benchmark](http://en.wikipedia.org/wiki/Benchmark_(computing))? – Bernhard Barker Feb 27 '13 at 16:40
  • 1
    Not sure. Just want to basically see how we're doing as an agency based on numbers. – Shamoon Feb 27 '13 at 16:47
  • 1
    Any decent programmer should tell you that number of lines changed is not a very accurate measure of anything. Sometimes one can spend days/weeks looking for a bug and end up changing only one line. – Bernhard Barker Feb 27 '13 at 16:48
  • 1
    Definitely a fair point. But there should be some averages. Exceptions are... exceptions. – Shamoon Feb 27 '13 at 16:49

2 Answers2

2

While I agree that for some tracking the number of commits and lines isn't the most useful metric for quality code, it can still provide you with a good birds eye view of how your company is doing. For development teams of more then 20 people being able to track your coders and make sure everyone is on track and moving forward with projects is a good thing to know.

Additionally some argue that it can take an entire day to solve one bug, but being stuck on a single problem can also be unproductive. Its better to keep moving forward then to get bogged down on a single item. Being able to know who is stuck helps me allocate my resources better and find those are frankly just not getting anything done.

If you looking for metrics like that i would recommend CodeGraphite or git-stats

Andrew Font
  • 1,245
  • 3
  • 19
  • 38
  • I would encourage you to read [this site's policy on self promotion](http://meta.stackexchange.com/a/59302/253560). [It appears you are affiliated with Codegraphite](https://www.elance.com/s/afont1991/resume/), so you need to disclose that affiliation in your answers that promote the product to avoid running afoul of this site's spam policy. – josliber Aug 24 '15 at 21:41
0

Creating a policy based on # of lines of code written is probably not the best way to go about it.

You should have some sort of well defined plan of goals/sprints/stories/ whatever you want to call them. A good practice is to commit as frequent as your lowest level of definition. So if sprints are made up of goals, and stories are made up of sprints, commit every goal.

It is good practice, also, to only commit fully tested and working code. Especially if you are doing trunk development, the trunk should ALWAYS be 100% tested and stable. If you have buggy code, keep it local, or in a separate branch.

In the end, commiting because I wrote X lines of code shouldn't be used as a standard. While it does provide some sort of redundancy in case of data loss, it winds up cluttering your commit logs with unimportant progress marks. Did I mention every commit should have a comment? Imagine what comments would look like using a line# policy.

'I added int x=0; and reorganized the source code so its more readible'

If I were looking through the log trying to find how the project has progressed after my week of vacation, I'd have to sift through all of those useless code commits

75inchpianist
  • 4,112
  • 1
  • 21
  • 39