How do you calculate productivity?

Let me start off by defining productivity -

It is the ratio of the quantity and quality of units produced to the labor per unit of time.

As we all know productivity is the measure of units produced in unit of time. But as you see in the definition above there is also quality involved in the units that are produced. So we can never calculate productivity only using quantity without quality.

When we think of productivity in software everyone goes for the easiest measure - number of lines of code written in unit time usually a man day. This is a very very dangerous metric to use for the following reasons

1. A lot of code is written by code generators and by copy pasting existing code and modifying it to suit ones needs. So there can be a large amount of code written in a very short span of time.


2. A good design may cause a lot of code reuse - thus reducing the amount of code that is written but in turn improving performance and maintainability. Does this mean that the productivity has come down.


3. Tough technical problems may have a lesser amount of code that is written than easier problems - but tough technical problems involve a lot of thinking and usually take longer to do. Does this mean that the ones working on the tougher problems are less productive.

Let me tell you typically what happens in a project that involves development of a business functionality.

• The initial framework and prototypes are developed - usually takes sometime and there is not much code that is written.
  
• Once the framework is proven junior developers are taught the framework and given the functionality to replicate using the framework - short phase when a large amount of code is written.
  
• Parallel activities go on to do the parts of the framework that are plugged in on top of the functionality such as security, error handling and so on - does not result in a great amount of code but achieves a large part of the functionality. Usually done by the senior developers in the project.

If you look at the above scenario it will come out that the junior developers that worked on replicating the functionality using a similar kind of an architecture are more productive than the senior developers that worked on the tougher defining parts of the application. So as you can see above the traditional LOC/Man day definition never works. What is more flawed about this definition is that it does not even take into consideration of the quality of the code. One may write a lot of crappy code generating a large amount of code base but the stuff does not even work.

At the end of the writing software is different from manufacturing - productivity is a concept from manufacturing. It is easy to use productivity in manufacturing for the reason that it is the same article that is being produced again and again each and every time. Hence you can either go fast or slow in producing that article and productivity is an apt metric there. The same cannot be said of software. In software we are not producing the same functionality over and over again.

More dangerously productivity tends to be used to evaluate the performance of the person and I hope that by reading what is on top no one in their right mind would use it.

Let us hypothetically say that we want to calculate the productivity in software - how would you do it?

In order to calculate productivity we need a measure of size or quantity. This is the hardest thing to calculate in software the reason being the easiest measure Lines of Code (LOC) can be very misleading. There can be code that is never used or called in the program. They can be code that is absolutely messed up and should never have been written that way. There can be code that can be written on the same line but is written on multiple lines or the other way around. There are hundreds of such issues with using LOC as a size measure. Which brings us to the only other measure and that is trying to count the functionality that is implemented. For this FPA (Function Point Analysis) does a pretty decent job but the catch is that it is not easy to use by everyone. One needs to have experience using it.

Provided you have the FPA count of the project - then comes the next challenge of getting the time to divide it by. One should never add the full duration of the project and use it. This is a big mistake. Each phase of the project has its own challenges and the outputs are different out of each phase. Productivity should be calculated on items where the output is similar if not same. Hence one needs to count the productivity for each of the phases - planning, design, development, Testing and Release (provided we go with the waterfall life cycle) separately.

Now comes to the third measure and that is quality. Quality can be calculated by the amount of functionality that is working with no defects or defects accepted with a work around.

Hence I would say a decent productivity metric would be FPA count/Time in x phase where y% of the functionality is working.