Pondering Programmer Productivity
Lots of discussion lately about measuring productivity has had me spending time I should be sleeping thinking about the same. I love accountants and finance folks. I find them very bright and love the way they typically approach any business discussion from the point of logic, but they can be an intractable lot as well. They’d love to measure software engineering efforts like a consultancy – hours in, output out, utilization metrics pop right out the other side of the equation. More utilization of the team means more productivity! Wonderful! Its so simple and we should have figured this out so long ago. All that time wasted counting KLOCS and function points….
Of course it doesn’t really work. You can count hours, or days, or whatever to your hearts content but you are only measuring effort. And, measuring effort of a software development group is an exceptionally tricky (and potentially dangerous) thing. Its not the effort that matters, but rather the results. So how do we measure the results? Ahhh there’s the rub.
What we need to measure is the business value of the stories the team is being asked to build. For the consultant this is very simple – you are paid by the hour for the consulting performed. Thus, hours billed X hourly rate = business value. The business value of a software going into a product is not so easily measured. But, lets assume this is a solvable problem. It gets even more interesting in the planning phase when you are making product choices. For a proposed feature, what is the busniess value? Now suddenly, this is not a software engineering question at all.