The best method for evaluating programmer productivity? [closed]

Question

Option 1. The number of lines of code per unit of time. Bad option. It's like measuring the readiness of an aircraft by its mass. Does not take into account the Chinese style.

Option 2. Works / does not work. Too primitive, does not consider optimization. The Bombay School of Programmers was here.

Option 3. The programmer or his colleague evaluates each other's work on the basis of their own experience. Depends on the programmer. Not objectively, but it can bring results or the case will end with holivar.

Option 4. The assessment is useless for the process and do not spend time on it.

Option 5. Fast micro assessment done for the day of work. Does not give an overall picture.

Who does how? I use option 5 + option 1 without taking into account copy-paste, Chinese code and taking into account comments, it turns out about 5–20 KB per day depending on the part over which the work is being done. What other options are there?

the finished product at the right time - the best estimate of performance
per day you can write as 500 lines of declarative code, and implement in 100 lines some rather complicated and important algorithm.
In general, as I noted, many programmers have a big problem of the form - “damn, Vasya Pupkin knows (knows how) something much more (better) than me - therefore I am no good for anything”, so - you cannot measure all by one measure .
PS: in my opinion, only your teams can really adequately assess your productivity
@igumnov Hmm, of course everything can be, but I recently realized that writing ~ 400 lines of correct production code and updating it in a day is very difficult.
Does anyone really consider their performance in terms of the amount of written code? .. You need to strive for quality, not quantity.

Accepted Answer · 2012-09-09T05:00:37

Option 6. Daily 5-minute tests / puzzles for programmers. Like assignments from instrumental skills tests. Especially in the morning.

Pros:

an objective assessment of at least the state of a person before the start of the day;
brain pumping for programming, with regular daily use of the benefits will be considerable.

Minuses:

where to take tests, constantly new, interesting, adequate to work and skills. You may have to buy tests;
metric divorced from work context.

Programmers will send such a boss to far away and do it right.
I am presenting the job description:> blah blah blah>> - a small friendly team> - interesting tasks> - daily five-minute puzzles
As for me, someone to whom, and without a programmer enough puzzles with his head
@sergiks The idea itself may not be useless (if you agree with the team and everyone will be strictly “for”), but I would not call this business a metric.

VladD 183k sixteen 222 432 · Answer 2 · 2012-09-08T21:35:48

There is no good well-known metric (and hardly can be), but no one bothers you to set a local productivity metric for yourself. You subconsciously know whether you did more today than yesterday, or less.
This kind of performance metric only makes sense in the context of a project, not a developer. I recommend to get acquainted with the information about the Theory of Constraints and about its spread to Agile processes.
In fact, with your option number 5, you partially re-invented the Daily Scrum Meeting .

@alexlz Well, the theory of restrictions and Kanban as its technological embodiment happily migrated to IT and got accustomed there.
So, roughly speaking, Chrysler and Toyota belong to Agile .
Kent has written XP and refactoring books and now runs his consulting firm.
It was a long time ago, in the past millennium ... Project C3 (Crysler Comprehensive Compensation System) avocallc.com/downloads/ExtremeProgramming.pdf

MSDN.WhiteKnight 13.9k five 26 56 · Answer 3 · 2012-09-10T13:53:55

Our team has been using the following scheme for a long time:

The team is divided into groups of 3-4 people, in each group there is a main one (usually a more experienced employee). His tasks:

distribution and control of tasks, it is closely related to the development process (almost every task in his group), therefore it is aware of progress
review documentation and code
assessment of the quality of the tasks and the effectiveness of the members of his group. The close interaction of people of one group practically guarantees adequate marks from the side of the group leader.

Group leaders will report to the team manager. The latter does not deal with technical issues; these are the duties of the "group leaders"; its main responsibilities are the resolution of organizational issues.

those. our scheme leans towards option 3

Shamov shamov 2,729 one 7 22 · Answer 4 · 2012-09-09T07:41:58

Absolute scale is impossible to build. There is no ideal programmer whose rhythm of work on any task would be optimal in terms of both development speed and code quality. But this does not mean that performance is not measurable at all. I use a relative metric for this.

Before starting each area of work, based on experience, I make more or less realistic assumptions about when I’ll finish, and then compare them with the actual time spent. If no force majeure occurred in the process, but there was a significant delay, then the performance was low. The number of extra hours speaks eloquently about how low. But it happens the other way around. The task is solved faster than planned, and at the same time I clearly understand that I solved the problem exactly as I planned - I did not simplify anything in the process. In this case, I conclude that I need to reconsider my own ideas about my capabilities for the better - in fact, I am better than I think about myself.

@Shamov, do you make these comparisons before multiplying the initial estimate by three?
As is well known in real life, the time required to get a program is equal to the time promised by the developer, multiplied by at least three.
It is due to the fact that after development there are still stages of debugging / testing and implementation.
So I can measure the performance only on the work site, which lasts until the version that “theoretically should work” appears.
@Shamov - "... based on experience, I make more or less realistic assumptions ..." and how often did you manage?
:) "If no force majeure arose in the process, but there was a substantial delay," I can’t agree with it in any way, if there is a delay, it means you didn’t know something, or you didn’t work, neither from the first nor moreover, from the second - no one is insured and, in my opinion, this way you can measure only “invested in the deadlines or not”
"It is connected with the fact that after development there are still debugging / testing stages" either you are working on something elementary, or you are a genius, or a hopeless optimist :)
Especially on a large interval, when there is an opportunity for internal maneuver: a subtask that starts to drastically reduce the intended rhythm, put it to the end ... at the end it is somehow easier to do - a lot has already been done, it remains to finish it off a little bit.

The best method for evaluating programmer productivity? [closed]

Closed due to the fact that off-topic participants LEQADA , Vladimir Glinskikh , Aslan Kussein , torokhkun , xaja Nov 6 '15 at 5:33 am

4 answers 4

More articles: