Reply to: Programmer productivity metrics

[chinglish]

I think you've missed the entire point of this thread. LOC is about the worst measure you could use to test whether something is well written. Chances are the better code in a project is concise and clear. The long winded code will hide potential issues that aren't obvious until out in the wild.

You missed my point which was first test the quality of code using open source tools available. These tools highlight useless/redundant code and programmers. If a programmer can't get his code to pass the quality checks then you don't need anymore metrics as the programmer is useless and you should get rid. If they can get through the quality checks then LOC remaining is one metric - on its own useless but a metric of quality code produced. The previous argument that a programmer can make their code long winded no longer exists as an automated code checker is included to highlight it. You can also when re-factoring use LOC removed - as a metric for how much more efficient the code is.

[eek]

What if the function's type is void?

Make it a boolean (success / fail) and ignore the response.

I've seen entire programs with that probably for that exact reason.

[Bunk]

As others have suggested, lines of code is not a useful metric. That's because, in any given function, usually only one line is actually coming up with the calculated value - the "return" statement. Getting a report of the number of "return" statements written would be much more useful.

I said "usually" there's only one return statement per function, but especially good programmers sometimes put multiple return statements in a single function. This is basically killing two birds with one stone, so those should count double.

hth
tl

What if the function's type is void?

[Lockhouse]

Very poor troll IMHO.

[eek]

There are enough code metric tools especially for Java - if you want metrics incorporate Checkstyle and Findbugs in your build script. Combined they will highlight duplicity cut n paste, inefficient code, security problems etc etc. By all means use LOC but only after they have passed checking by Checkstyle and FindBugs.

I think you've missed the entire point of this thread. LOC is about the worst measure you could use to test whether something is well written. Chances are the better code in a project is concise and clear. The long winded code will hide potential issues that aren't obvious until out in the wild.

[chinglish]

There are enough code metric tools especially for Java - if you want metrics incorporate Checkstyle and Findbugs in your build script. Combined they will highlight duplicity cut n paste, inefficient code, security problems etc etc. By all means use LOC but only after they have passed checking by Checkstyle and FindBugs.

[kingcook]

What is a good metric of productivity of programmers? I get the impression some of my dev team are slacking off and have asked the lead to send me a weekly report by developer of how many Lines Of Code each has written. However I am getting strong push back on this so I need an alternative.

What does the panel recommend. Also, what is so wrong with LOC as a metric. If I was running a potato factory I would want to know how many spuds each worker had peeled, same difference in my view.

Fecking prima donnas

Number of lines of code, definately. I've made a good living on it. Did I mention that I like to write lots of useless comments?

[thunderlizard]

As others have suggested, lines of code is not a useful metric. That's because, in any given function, usually only one line is actually coming up with the calculated value - the "return" statement. Getting a report of the number of "return" statements written would be much more useful.

I said "usually" there's only one return statement per function, but especially good programmers sometimes put multiple return statements in a single function. This is basically killing two birds with one stone, so those should count double.

hth
tl

[IR35FanClub]

Function points.

Did a course once. Useful. Some companies price their contracts using them.

They are language independent. But you have to work out how to convert function points to pounds using your own empirical evidence from the tool set you are using.

[SunnyInHades]

#define fastcopy(x,y,z)

fastcopy(array1, array2, size);
fastcopy(array1, array2, size);
fastcopy(array1, array2, size);
fastcopy(array1, array2, size);
fastcopy(array1, array2, size);
fastcopy(array1, array2, size);
fastcopy(array1, array2, size);
fastcopy(array1, array2, size);
fastcopy(array1, array2, size);
fastcopy(array1, array2, size);

/* Copy'n'paste 'fastcopy(array1, array2, size);' which does nothing as many times as required.
Scatter liberally through files and within methods to taste -
no nosy line manager peeking at version control checkins will dare delete or question such lines */

[NotAllThere]

I think it's easier for bad coders to get away with it. You can knock up something that looks half decent with a bit of drag and drop. You can write pages of inefficient code and bad database queries, but because the machines are powerful, performance isn't a problem.

I'm currently investigating performance issues for a client... the inefficient code rapidly becomes apparent. I've gathered evidence that the offshorers aren't even following their own inadequate standards.

[mudskipper]

I've often wondered what would happen if companies really measure the TCO of every development. I.e. initial development, rework, costs results from errors when the code is live etc.

Research last century suggested that a "good" programmer is 20x better than an "average" programmer, in terms of TCO. And 50x better than a "poor" one. My experience this century is that even half-way decent programmers have become quite rare. All due to saving money by offshoring.

I think it's easier for bad coders to get away with it. You can knock up something that looks half decent with a bit of drag and drop. You can write pages of inefficient code and bad database queries, but because the machines are powerful, performance isn't a problem.

[NotAllThere]

Must be a troll surely?

A better, more experienced programmer will write less code than someone with less experience.

A smart arse programmer will try to write code that is TOO concise.

I've often wondered what would happen if companies really measure the TCO of every development. I.e. initial development, rework, costs results from errors when the code is live etc.

Research last century suggested that a "good" programmer is 20x better than an "average" programmer, in terms of TCO. And 50x better than a "poor" one. My experience this century is that even half-way decent programmers have become quite rare. All due to saving money by offshoring.

[NotAllThere]

What is a good metric of productivity of programmers? I get the impression some of my dev team are slacking off and have asked the lead to send me a weekly report by developer of how many Lines Of Code each has written. However I am getting strong push back on this so I need an alternative.

What does the panel recommend. Also, what is so wrong with LOC as a metric. If I was running a potato factory I would want to know how many spuds each worker had peeled, same difference in my view.

Fecking prima donnas

Sir, you are without a doubt a complete tool. Your understanding of the development process could be written on a piece of paper the size of a postage stamp, with a marker pen. Lines of code as a metric? Yes, sure. As a trolling attempt 0/10. I'm bored with this sockie - perm-ban.

[oscarose]

There is only one true measure of who is top dog. Their daily rate. Just ask The Other Contractor.

+1