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.