August 3, 2007
Is "Productivity" Incompatible With Innovation?Measuring development team productivity is an extremely tricky problem.
But it's one that comes up time and time again, and even cynical old software hacks like me catch ourselves dropping the "P" word into polite conversation where it arguably has no business being.
Ask me about defect prevention, for example, and my knee-jerk response is to say that it "improves productivity". What I actually mean to say, of course, is that it reduces avoidable rework caused by bug fixing later in the development cycle. Reducing wasted effort is not the same as improving productivity - at least, not necessarily.
In a process of innovation, "productivity" is a very slippery customer, whose meaning is very difficult to pin down. The traditional 19th century management view of productivity, born out of the industrial revolution and the metaphor of business-as-engine, summises it as:
productivity = output/input
It is "miles per gallon", or "donuts per person-hour" or "$ profit per $ invested". Simple, yes? Except that it only seems to apply to simple operations. And software isn't simple.
Unfortunately, outmoded industrial thinking is still being applied to a whole host of management problems that are just too complex for output/input to be meaningful. And software development is definitely one of them.
Which is why we've ended up with some overly simplistic and - let's face it - pretty spurious measures of software developer productivity in the last three decades. Lines of code / (mythical) man-month. Function points/ iteration. Features / $1,000. Do any of these sound familiar?
The problem with all of these measures is that they imply that more software = more value, and that most certainly is not always the case. For a start, more software means a higher total cost of ownership, since more code will require more maintenance over its lifetime. If you rewarded development teams for this kind of "productivity", you would be encouraging them to over-complicate.
And what about bugs? The more code there is, the more there is that can go wrong. Indeed, teams that tend to produce a lot of code quickly also tend to introduce a lot of defects into that code, making for a terrible hangover in subsequent releases.
And what about usability? And scalability? And reusability? And security? There are potentially an infinite number of qualities we might need to achieve in the code we deliver, and output/input doesn't begin to address them.
And most importantly, what about value? No matter how well-engineered, simple, elegant, secure, reliable, robust, usable, reusable and anythingelse-able the code is, what is it worth to the people who use it and the people who pay for it?
More recently, some more informed people have tried to reinvent productivity by substituting value for output, and cost for input - which, to my challenged mind sounds more like developer profitability. This makes more sense, but is still hampered by two major handicaps:
1. Determining the value of software is very, very difficult
2. Not all software has financial goals
The second point is the killer, for me. It is naive these days to think that the reason for building a piece of software will usually be to make or save money. Sometimes - though nowhere near often enough - it can be created to save lives, or to empower communities, or to educate and inform, or to explore and discover.
A software project could have any of an infinity of possible goals, just as the software it creates can have any of an infinity of possible qualities. And most of those goals can't be measured in financial terms.
So if we find ourselves working on a software project that has non-financial goals, whence our "productivity" then?
I believe that productivity is a red herring in any process of innovation. It doesn't really mean anything, and we would be wasting our time trying to measure or persue it.
Wasted effort is worth measuring, because - no matter what the value of what we're producing - it surely can't hurt us do it for less?
It still doesn't solve the problem of how we increase the value of the software we deliver, and you could easily argue that - given those two levers to pull: value and cost - we could achieve exponentially more by pulling the value lever, because there are very real limits to the economy we can achieve in software development.
But it's a start, and it does have a quantifiable value. And with those in the software development community - and particularly in the Agile community - who maintain that it's the customer's job to define the value in a project, you could just as easily argue that economy - and not value - is the responsibility of software developers.
Which takes us full circle. Our simplistic definitions of productivity don't address value, but value apparantly isn't our problem, so maybe it doesn't matter. Maybe output/input will work for us after all?
Which is patently nonsense. And that's how I know that value is our problem. We have a responsibility to help guide our customers and to question the value of everything they ask us to deliver, as well as continually testing their priorities. If we don't do it, then we're probably fools to think that they will.
Posted 13 years, 4 months ago on August 3, 2007