Skip to content


December 1, 2008

I was in a meeting last week and this scenario was brought up:

A work has 100 tasks to do in an 8 hour day then the worker automates the process to do all 100 tasks by pushing one button. So, instead of doing the tasks manually that takes 8 hours, the worker drives into work logs onto a computer then presses the button and goes home. Is the worker still just as productive?

Of course this question got me thinking. I concluded that yes in the short term the worker is just as productive, but in the long term the work is NOT as productive.

This was a general question but I am going to gear it towards evaluating and measuring the productivity of programmers.

The first thing that needs to be stated is that productivity is relative (as are all things). What was productive in the past is no longer, due to the advancement of technology and better processes.

Defining productivity is hard a vast number of people in the field have tried and productivity the definition and measure of it is most likely specific to the company. Here is my attempt at the definition:

Productivity is working to your full potential over some period of time. In the case above both individuals are working to their potential in their time periods, however, the difference is the worker that only presses a single button could get much more done with the extra time now available to him/her.

Now lets get a little more specific towards the programing arena.

1. What does a manager need to account for when determining if their programmer(s) is/are productivity?

Abstractness of tasks, difficultly of tasks, past performance, estimate vs actual time spent on a task, understanding of the problem, customer satisfaction, bugs found after completion, good programming practices, efficient and well documented code and numerous others all contribute to a programmer’s productivity. From this list it is easy to see that determining if a programmer is productive is not easy. The harder item to determine may be if the programmer is improving or at a level that is expected.

2. Are there statistics or metrics that can be used to evaluate a programmer’s productivity?

Lines of code divided by bugs found is a common metric, however, along with many other individuals in the field, I believe this statistic is not a very good indicator of productivity. Currently my view is that estimated time versus actual time combined with the number of bugs found after completion is the best way to determine productivity. A programmer could zip through a task but then have to spend much more time after the fact. Where as a programmer that took time to document and write “good” code (that is a discussion for another post) will spend more time up front and less time after the fact.

3. What are some other non-programming tasks and/or attributes to consider when determining the productivity of a programmer?

– Research into new technology and/or algorithms to help solve problems.
– Communicating with the client to determine client needs and wants.
– Communicating with people that how better knowledge about the task.
– Continuous improvement process (read last post).

In review productivity of a programmer depends on the situation of the company. However, by using estimates versus actuals combined with time spent after completion should give a good insight into the quality the programmer is outputting.

I must note this is all theory on my part, since I have only been in the field for about a year and a half I currently do not have any programmers to manage. So I have no means to test these theories besides on myself (and with such a small sample set the results may be skewed). So, in the time until I get my own programmers to manage I will have to manage myself and determine how productive I am and how I can improve the processes to become a better programmer.

  1. Mark Robinson permalink

    Productivity is the amount of output per unit of input. The input is Labor(time spent coding) then what would the output be? Number of lines of meaningful code? There are just to many variables for this to be useful. Productivity is better suited for repetitive jobs rather then problem solving jobs.

  2. then how do you know if your programmers are getting anything done

  3. Mark Robinson permalink

    <>“then how do you know if your programmers are getting anything done”<>Answer: The results of the hours input.A software project should be broken down into small manageable steps that the developer estimates they could reasonable complete within 1-3 days. During the coding of a project how do you know if anything is getting done ? Look at the status of the sub tasks.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: