How to quantify the work perfomed by a developer/programmer? [duplicate]

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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".

Answer 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.