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!

architecture, engineering, programming, software, to_read, toread

Comments

[bebraw]

This is the reason why I like to advocate lean/agile approaches to software development. Note that I'm not saying other ways cannot work. :)

It really doesn't matter if you are being productive using some fancy metric. The key thing for me is customer satisfaction. Are you solving the right problems to achieve this?

It's extremely easy for us software developer folks to get stuck on some non-essential detail that really doesn't deliver much value to the customer. Leaner, less prescriptive approach to software development forces us to focus on the right things.

[Benjamin Manes]

This is what I love about Pivotal Tracker. Its simple, provides visibility & priorities, and isn't process heavy. As a developer its a dream as it lets us manage tasks as either in-progress, scheduled (backlog), or unscheduled (ice box). We can provide weekly status updates based on our velocity, plan out projects, and easily adjust based on changing need.

I love it and I absolutely hated the mico-managing, proccess centric, painfully slow VersionOne. I also found the uber macro-management with clear no direction and secrecy frustrating, but at least it enabled the freedom to be productive. But Pivitol, wow... that's one tool that will make your developers happy.

(No association, just happy user)

[Moutasema]

So true, actually i got adrenaline rush when working with great team and great framework with magical syntax.. so all you need to do is write wht u wnt to happen instead of writing how it should happen

[Jchyip]

Have you read How to Measure Anything by Douglas Hubbard?

[Dan Pritchett]

Nope, but I will add it to my reading list. Thanks!

[Sri Shivananda]

While there may not be a universal numeric index, productivity is clearly visible, comparable in context and addressable / tunable.

I have sometimes used a negative measure of "time wasted" in non code producing tasks as a close enough proxy.

Productivity comparison across developers is a somewhat futile task. There are developers who are 10 times more "productive" in the same environment due to the difference in education, training, planning, discretionary effort, creativity etc.

I believe measuring same developer productivity and eliminating or optimizing time spent in activities like developer desktop setup, workspace setup, builds, server start-up, hardware provisioning, dealing with engineering rot coming for bad code hygiene, deployment etc. should always be a goal for engineering leaders.

Then there are personal productivity optimizations like how often you check email, how much time you spend in meetings or how you manage time slicing on a project that impact how productive a developer is as well.

[Daniel Sobral]

Who was it that said LoC should be counted as cost, not as deliverable? Wise words...

[Farhang Kassaei]

It depends what type of productivity is measured and how it is used (and by whom). I agree that defining and measuring productivity per developer (micro-productivity) is next to impossible, they are simply too many variations, it is like measuring the total distance a soccer player runs during a game - it does not matter. However there is notion of macro-productivity (much like what economists measure for each country). But it has to be measured as an aggregate and has to be used to improve the overall software engineering discipline in a unit (not to judge individual performance by). One simple (or simplistic?) was is to divide unit of output (one application - I know we don't even agree what an application is :-) divided by input (developer*hours). It is crude, and it MUST not be used as an absolute measure, but if it is measured for the same team building three, four applications, it gives you a good indication of how your platform (tools, processes, libraries, runtime etc.) enables your people (or conversely how effectively your people utilize your platform)