Over time, there have been many attempts to define metrics that effectively measure software development productivity. Most of the ones that I have seen are amazingly complicated and very difficult to apply.
I think there is a simpler productivity metric which should be used across the industry: the total number lines of code in the organization divided by the number of people who are working on that code (including QA as well as development). For short, I will call this metric the LOC per head.
I propose that this measurement is an excellent representation of the development organization’s true productivity. If the number rises, it means that the development organization is more productive. If it decreases, it means that the organization is less productive
Approximately 10-20 thousand lines of code per developer is the norm for most of today’s development organizations. This is based on the current industry averages which state that a typical program has about half a million lines of code, and there are usually about 30-60 developers working on that code base.
So, how does the metric work? Imagine that an application is being actively developed, and a lot of code is being written. If the LOC per head is high, it means that you have a relatively low number of people working on code—you are accomplishing a lot with minimal resources. If you add more people to the project because the requirements are not being implemented fast enough, then the productivity of the requirements implementation goes down because there are more people working on that application. When you need to add people to the project, it indicates that the current team doesn’t have a high enough productivity to keep up with the schedule. It doesn’t matter how fast individual developers produce code. That’s a different issue. As your average LOC per head drops, it means you are applying more people to build the code.
If a team is responsible for maintaining a large application, any change to the code base might have a tremendous impact if the developers do not fully understand the code base. If the team’s current developers are having a difficult time understanding the application— this is typical with maintenance projects— you will very likely need more people so they can subdivide the application into more manageable parts, reducing the amount of code that each person has to learn and understand. Since each person will then be working on a smaller amount of code, productivity would decrease as a result of adding more people to the project. If the team was later able to effectively maintain the fewer developers— where each developer was familiar with and working on a larger section of the application— they would then be more productive.
This is the metric that I use to measure development productivity, and from what I’ve seen, this number never lies. Code is the product that represents the application. It’s still an effective measure if the LOC includes comments, and it applies equally well if code is in maintenance or development phase. In any case, when the metric is higher, it means that more code is being handled by each developer. It is not perfect, but it is a reliable measure of productivity.
Dr. Adam Kolawa is the co-founder and CEO of Parasoft.