9

This question already has an answer here:

I know the best four naive ways of achieving this.

  1. Commit count: In the code repository count the number of commits done by a user. However this is just what the name says, counting the commits. It cannot separate near empty commits from commits having hours of thinking and sweat.

  2. Line count: Counting the number of lines of code produced by a developer. However developers can practice verbose programming, use inefficient algorithms which take lots of code to be made, or just create ugly and large code. So it is hard to use this as a good metric of the work performed.

  3. Time count: I could count the time that a developer spent working. But no one can work one hour straight. Moreover, some programmers can preform 2h of work in just 1h, and vice-versa. And in the end is not the time that counts but the progress the project made. I don't care if a developer spends 5 years or 5 minutes coding, in the end the project is to be completed in its due date. This leads to our final bullet:

  4. Feature count: Counting the number of features closed by a developer will keep track of the overall project's progress. However I cannot tell if those features were toy-features or they were insanely hard to accomplish. Moreover, I cannot tell one developer from another in order to see who performed most of the work. I could estimate the difficulty of each feature, however most of the times that is unfeasible because (i) it is frequent that unexpected problems arise during a feature, (ii) we tend to over simplify things, (iii) for some significant amount of features the work of estimating their difficulty greatly overlaps with the task of doing it, i.e., we can only know how long it takes to close that feature after closing it.

So, in the end, how can one measure, quantify and compare the work performed by developers in a project?

marked as duplicate by durron597, gnat, Daenyth, user40980, user22815 Jun 16 '15 at 0:13

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 14
    It is just not easily and reliably possible. Sometimes, removing thousand of code lines from a project is a huge progress (but does not add any externally visible feature) Read the mythical man-month and no silver bullet – Basile Starynkevitch Jun 15 '15 at 10:30
  • 7
    Imagine you had a programmer on the team who spends all the time reviewing other programmers' code before commit. Would your proposed metric make that zero productivity or the only productive team member? – o.m. Jun 15 '15 at 15:11
  • 6
    Why can "no one can work one hour straight"? I can work for much longer if I'm in the groove. – bjb568 Jun 15 '15 at 18:10
  • 3
    1 & 2 would be actively harmful! Especially 2! Why would I call existing functions when I can just copy and paste them into my 9000 line function – Richard Tingle Jun 15 '15 at 18:31
  • 3
    Relevant: -2000 lines of code – Mason Wheeler Jun 15 '15 at 18:47
33

You cannot measure and you cannot quantify. Give those ideas up from the beginning. Peopleware goes into great detail about how some people offer value simply by being catalysts for the rest of the team. Those people must not be dismissed because they're not producing lines of code. Likewise, we've all worked with developers who churn out work but are so destructive to the team (through attitude or carelessness) that the team is better off without them.

You can quantify the value of a team, by what functionality it provides for the business and what the business gains from it. But that should be done only at a team level.

You can also compare developer value within a team. But not necessarily in the way you're thinking. It's all about peer-review through creating regular feedback opportunities.

Start with stand-up meetings every day. A developer should always be able to justify to other developers what they were doing the previous day. To be clear, stand-up meetings are not designed to justify a developer's existence. And if the meetings feel that way, they will cease to work. But a stand-up meeting is a regular feedback tool and thus, by nature, will immediately give you hints about problem developers.

That is, sometimes a stand-up report is going to be "I achieved nothing because..." but that's fine, as long as it's not every day (although if it is every day, you want to consider that a management failure before deciding it's an individual failure).

Next, start doing 1-to-1 meetings. Regularly, reliably, off-site and anonymous. You'll quickly learn if an individual is a drain on the team or if another individual is a consistent benefit.

Finally, do regular, periodical 360 reviews. Make no mistake, these are hard to get right. It must be anonymous and seen to be anonymous; ideally collated by an independent third-party. But if you do it right, this is when you'll start seeing an actual numerical value of one developer compared to another. And, perhaps more importantly, of your value as a manager.

  • 6
    +1 for cannot measure and cannot quantify. My first thought is of the WTFs per minute comic. – Telastyn Jun 15 '15 at 11:27
  • 2
    I agree totally with the first 3 paragraphs but I don't think you need to do anything to evaluate how well developers are doing in a team environment other than pay attention and listen to what is happening day in and day out. No need for meetings, no need for reviews. Just pay attention. This is harder to do when teams are disjointed, people work alone on projects or the manager is on manager row instead of with the team, then I guess you'll need to do the stuff you are suggesting. I am always amazed at how quickly the pecking order of skill level and usefulness works itself out on teams. – Dunk Jun 15 '15 at 17:55
  • 2
    I would add that the programmers on a team generally know how much each other is worth. Mind you, a good person won't say bad things about others, but I believe if you ask them about each other's work product, you'll be able to tell who the programmer actually thinks contributed to the team and who did not. The 1 on 1 meetings and 360 reviews are a (and not the only) management tool to obtain this feedback. Find management tools that work for YOU, not the ones that are most trendy or popular, and you'll find out what you want to know. Teams win or lose together, so be careful. – Guy Schalnat Jun 15 '15 at 20:58
  • 1
    @Telastyn Source, for those who don't know: osnews.com/story/19266/WTFs_m (Assuming there's anyone left who hasn't seen that, of course. XD) – Ajedi32 Jun 15 '15 at 21:30
  • 1
    @TylerDurden - 10 minutes of meetings to head off hours of issues due to miscommunication or no communication, and hours of mind numbing manager involved meetings? Well worth the trade, and nearly universal in software houses these days. – Telastyn Jun 15 '15 at 22:12
8

You measure it by spending the hours necessary to manage the project.

If you wait until all is said and done, you have no way of pulling statistics out of the final product. You can't even look at the artifacts of the process and measure the contribution levels automatically without falling back on the naive statistics.

As progress is made during the project you mentally determine who are the strong and weak contributors. You adjust their workloads to match their skills, strengths, and weaknesses. By the end of the project you will have a good idea the relative rankings of each part of the project team as it relates to your project.

  • 1
    Evaluating individuals relative to the team is much better than individual performance in isolation. Writing a great essay on ancient history gets you no points in math class. – JeffO Jun 15 '15 at 14:38
4

All of the measures you propose are naive and bad, however, some are much, much worse than others.

Specifically, the first three are very bad - in fact, trivially subverted. Only the last one - implemented functionality - should even be considered in a business decision.

Obviously this measure lives and dies by how well the "functionality measure" maps to actual business value. That is a grave problem, but it's one that you have to solve anyway! Someone, somewhere, must make estimates about the cost and the benefit of any given feature, story, function point, whatever you call it, because that's the only reasonable way to decide which of them to do and in which order. Whatever measure you use to make these decisions should also be used to gauge the value added to the business by the ones implementing them.

  • 2
    So the programmer should avoid taking on difficult to develop features that don't add as much value to the business? It seems like another way to game the system. – JeffO Jun 15 '15 at 14:35
  • 3
    The team should strive to avoid taking on difficult to develop features that don't add as much value to the business. – Mike Partridge Jun 15 '15 at 18:42
  • 2
    @MikePartridge - You can't just pick the low-hanging fruit forever. – JeffO Jun 16 '15 at 8:29
3

The purpose of developers is not to "write code". The purpose of ANY engineer, be they software engineer, civil engineer, or whatever is to SOLVE PROBLEMS.

Therefore, it IS possible to judge a developer on their work, but not in any of the ways that you listed (sort of...).

Number 4 is on the right track, but not quite complete. Judge developers on how well they:

  1. Interact with their business users/team members (if you are a big enough company to have BA's, then substitute business users with BA's)
  2. Solve the issues presented to them. Do they take an inordinate amount of time compared to other developers to solve similar problems?
  3. Abstract complex issues down to smaller chunks of work and create meaningful subtasks, and then execute on those subtasks.
  4. Add value to the business.

As you can see, it isn't easily quantifiable. Just like many other professions, it is about concepts far more nebulous than "how much code they write".

  • Good points. The better programmer is the one who "doesn't" add little dancing frogs to the accounts payable app just because some user thought it would be cool. – JeffO Jun 16 '15 at 8:14
-5

Committed line count is the measure I use. I find it is reasonably reliable. There is a big difference between a guy who is committing 15,000 lines a year and another who is committing 3,000 lines a year, and another who is committing 60,000 lines a year. Back in the day when I wrote a lot of code I maxed out at about 50,000 lines a year. The best programmers I have had personal experience with do about 200,000 lines a year. Guys that do that, the real burners, have to be very heads down and are hard to find. One guy I knew who was that level is a VP now and makes $500,000 a year.

You also have to take into account whitespace. There are some guys who put every brace on its own line, so you have to multiply by 0.8 to adjust for all the white space. In general, though, its just tweaking. Usually the good programmers will be producing double or triple or quadruple what the weakies do, so the whitespace doesn't really matter much in the long run.

The very first year I worked full time as a programmer I wrote an MS Access DB application. It took me the whole year to write it. After the whole thing was written and fully debugged and working, I did a line count. It was 400 lines of code. Nowadays, I could write that same application in a single day. Gives you some idea of the difference in skill. Nowadays, if I go all out, like its Goole Code Jam or something I can write about 1000 working/debugged lines a day, so in theory I could do 250,000 lines a year if I did nothing but program. Of course, I spend all my time now going to meetings, writing specs, winning new business and answering questions on SO, so I do a lot less than that.

Because of this last factor, you have to weigh what the person is actually doing. Do you have them spending weeks writing specs or help files? That is going to hit their line count. Are they talking to clients or bidding for business. Ditto. The line count is mainly an accurate measure for guys who are strictly coding.

Note that you have to take into account what phase the project is in. If the project is new, the line count will be a lot higher than an old project that is getting debugged. Also, as projects get big and hairy, the line count decreases somewhat.

You will find some "manglers" out there who have the idea that measuring by commit count will encourage people to commit junk code, but in practice that is not what happens. Anyone who commits a lot of junk ends up wasting a lot of time debugging, so they don't really gain anything by committing junk. In general, the more productive a coder is, the higher quality their code is, and in fact, it has to be. If you are writing 1000 lines a day, they better be GOOD or you will spend a lot of time debugging.

------Postscript

I think it is pretty comical that the number one answer says there is no way to quantify programming skill/productivity and then recommends that you have a lot of meetings. LOL. The icing on the cake is that the guy is from London, the epicenter of the program-by-having-meetings world.

I guess I should modify my answer somewhat. I was assuming that what you were trying to do is write working computer programs. If you work for a big, rich, entitled company where the goal is to maximize employment, make your government happy, be green, and have a wholesome work environment where everybody is social and nice to everybody, then by all means have lots of the meetings, that's the secret to success. Measuring people is bad, might make them feel inferior, can't have that.

  • 1
    Why don't you just go ahead and pay 'em by the line. That will get you some great maintainable software I'm sure. – RubberDuck Jun 15 '15 at 22:27
  • +1 for being a well-considered answer from a newbie. That said, it really simply encourages committing as much as possible without regard to necessity or quantity. – Matthew Flynn Jun 15 '15 at 22:48
  • 2
    This answer couldn't be further from the truth (the author spent quite an effort on the research, that's the main reason it's not downvoted). Please see other answers for details. – Ruslan Osipov Jun 15 '15 at 23:00
  • If everyone is working on the same code base, I think this probably holds up. There's a different between building one complex application over the course of the year compared to 5-6 simple apps that are probably going to have a bunch of redundant code (separate clients). – JeffO Jun 16 '15 at 8:11
  • 2
    This is incredibly bad advice. The worst programmers I have seen all have one thing in common: They write lots and lots of code to solve simple problems. – JacquesB Jun 16 '15 at 8:39

Not the answer you're looking for? Browse other questions tagged or ask your own question.