What is Software Productivity?

People in every field are concerned about productivity. They want to know how to increase their own productivity and the productivity of their group.

Software is a peculiar field in which history is ignored and fashion too often trumps objective fact. In software, we don't even think about productivity, much less have any idea how to measure it.

What is Productivity?

Productivity measurement is central to our economy as a whole, to industries as a whole, and to individual companies.

In general, the more productive you are, the more outputs you generate for a given set of inputs.

Productivity can be measured by various means, depending on the purpose of the measurement. At the level of the firm, the most basic measurement is comparing the cost of the inputs to the value of the outputs, adding in overhead and the cost of the capital and labor required to produce the outputs.

Increased productivity can be accomplished by greater automation, improved processes, reduced cost of inputs, labor or capital, and by more effective use of labor, labor that is higher quality, more discliplined, trained and motivated, etc.

This is basic economics. It is applied from the national level down to mom-and-pop firms.

What is Productivity in Software?

Measuring software productivity is incredibly important. But practically no one actually does it! It's not even studied in any meaningful way -- if it were, you'd find competing theories, and experiments to settle the issue. While there are a couple studies, their paucity and narrowness prove the case that software productivity is largely ignored, both in theory and in practice. GIven that software is increasingly the engine that drives our enterprises, this is amazing.

The situation with software productivity is a bit different than in your basic widget factory.

• The cost of the inputs is pretty much zero
• For all the talk of software factories, the cost of "machines" is generally insignificant
• While the quantity of output (lines of code, LOC) is tangible, it's not really correlated with value
• Except in a few cases of commercial software products, the value of the output can be hard to measure, and even then it can be dicey.
• The overwhelmingly important factor in cost tends to be labor!
  

Software Productivity: the best case

To understand software productivity, let's start with an extreme case, but one that does happen a small percentage of the time.

A single person understands the requirements of what is to be written. That individual, perhaps with the assistance of one or two other people, writes, tests and delivers the code. The code runs in production for a number of years, and the few bugs that arise and the enhancements that are needed are quickly supplied by the original author(s).

In a case like this, the value of the outputs can still be hard to measure. But at least the other costs are easy: it's basically the cost of the people, with overhead.

Is this a fantasy or does it happen in real life? Well, all I can say is that it happened in my life, more than once, and I know people who have done similar things. In my first job after college, I wrote a commercial FORTRAN 66 compiler and run-time system (in assembler language) for a computer company. I had an assistant for part of the run-time environment. It was in production use for about ten years. I fixed a couple minor bugs in the first year, and that was it. I personally did a couple similar projects in different software fields.

In the case of the compiler, the cost was easy to measure. The value was typically challenging, but not too hard. The company sold the compiler. But its greater value was enabling sales of the display computer on which it ran. Potential buyers were refusing to buy because there was no high level language available at the time; my compiler enabled many sales that otherwise would have been lost.

It's easy to imagine the software productivity in this simple case. You can pick your measure of value (pick a few -- why not?), including lines of code, number of users, value of the code, indirect value. You pick your measures of cost (again, pick a few) including person-days, elapsed time, salaries, etc. And finally, you relate them into simple, calculable numbers that you can track over time.

Software Productivity: the Reality

In practice, software productivity is an absolute bear to measure. Cost isn't too hard. But valuing the outputs? That's the big problem. The other problem is that software just isn't like a widget factory. The items ("pieces" of software) cranked out are simply not comparable to each other, as I've discussed.

Conclusion

Productivity is important in general, perhaps even more in software than other fields because it is so hard to measure. Software won't get better until we increase its productivity, and that won't happen until we are hard-nosed and objective about exactly what software productivity is. All the discussions in this blog about software quality, estimating and other things are best understood in the broader context of software productivity, the great unknown frontier of computer engineering.

Comments

[Jim B.]

The best new one I've seen is Facebook's "push karma", http://www.facebook.com/note.php?note_id=10150660826788920

Very simple almost crude, but everyone openly has a score they're judged by that says they get this quote:

"From the time they check their code into our source base until it's out in front of their moms, our engineers understand that they're the ones who need to make sure it works."

Someone with good push karma might not necessarily be productive, but they are at least far less counter-productive.