Let's Kill Productivity!
Yes, let's kill productivity! Okay, not productivity but all attempts to measure the productivity of software engineers. It is a flawed, pointless, futile attempt to put metrics on something that is immeasurable. The energy spent on this could be applied to far more fruitful endeavors making everyone happier and ultimately that may be the one thing we can and should measure...happiness.
At this point, I've probably alienated many managers from all disciplines and have the full attention of many engineers. So, it is time for me to explain myself. Productivity is a measurement of efficiency. It's an attempt to create a metric based on volume of work over a unit of time. And there are many jobs where productivity is a perfectly reasonable metric. If I have a factory producing a titanium uber-gadget, the work is very well defined. Each gadget, especially since it is both titanium and uber, is identical. It requires the same components, assembled in the same way. Since the result is predictable, the effort required to produce the result is equally predictable. And if I want to improve the productivity of the people building the gadget, I simply look at what consumes their time and find ways to reduce that time via process design improvements.
Some of you may see a flaw in my logic. But wait, you are thinking. This is exactly like software. We improve our processes and our engineers become more productive. While that is true, it is not completely true and it comes back to the simple fact that software productivity is unmeasurable. The reason is that software isn't a precise product. There is no output that is uniform and measurable. There frankly is no meaningful way to measure the work so therefore there is no way to measure productivity.
But what about lines of code? Developers write code so measuring the quantity of code produced must surely be an indicator of work. Unfortunately there are two major problems with code as a measure of work. First, not all code is of equal difficulty. A 20 line method may take 10 minutes to write and test or it may take 10 hours. The variation depends heavily upon the problem the 20 lines of code solves and how much effort is required to solve the problem. Second, measuring the volume of code can reward engineers who write more code but not those that write good code. To paraphrase Mark Twain, "If I had more time I would have written less code." Being concise takes time and concise code is usually better than verbose code.
What about measuring feature velocity. The pace at which developers deliver features (stories, tasks, pick your unit) clearly is a measure of productivity. This is in fact true. Unfortunately what is missing from this measurement is uniformity. Product features are not of the same size or complexity so you can't simply measure the number of features delivered. It is also very difficult to normalize the feature complexity so while the goal is to measure business value delivered, putting actual metrics on it is almost impossible.
So if you can't accurately measure work, then how can you measure productivity? The simple answer is you can't and it turns out this is true for all creative work, not just software engineering. So if you can't measure productivity but you want to improve your processes, what should you measure? How about how satisfied your developers are with the process of building your product. Your goal is to build a great product with high quality which is more likely to happen when the people that are building it are enjoying the process. And perhaps this is the reason that great processes provide empirical evidence of higher productivity. They allow people to work on problems in a way they find rewarding and effective which leads to a better product. And measuring developer content is a lot easier, just ask them!
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)