The Skeptical Methodologist

Software, Rants and Management

Yes, Ben, there is such a thing as software productivity.

Ben Rady, on his blog Radyology, did his part today to perpetuate the myth that there’s no meaningful way to measure software productivity. This has to stop.

First, let’s get some things out of the way. I am not saying Software isn’t a craft, or isn’t art, or beautiful or whatever. In fact, I can make a very convincing case that many of the things we end up resorting to the language of art for, such as defenses of elegance, have a very strong business case behind them too. We needn’t retreat to other domains when the suits come in and ask for dollar signs into the language of poetry.

To go into how we should begin to think about measuring productivity (and I do mean begin because so far our thinking on the subject has been very weak), let’s look at Ben’s example. Frank and Peter both accidently get assigned the same problem to work on. Frank hacks together a 1000 SLOC framework that solves the problem beautifully, adds in documentation, testing and everything else. Peter takes a nap, comes back, deletes 100 SLOC of code and the problem is fixed. The question Ben then asks is who was more productive?

It’s obvious that Peter was more productive, but the point Ben is trying to make – if you’ll bear with me in deconstructing Ben for a big – is that he’s been in situations where Frank was instead the one who was recognized for solving the problem and frequently given accolades for his ‘productivity’. It may have been argued to Ben in the past, as well as many of us, that Frank simply produced more and thus must have been the more productive one. Frank made more stuff. Frank is more productive.

Radyology has countered this argument with saying productivity doesn’t matter, or that it can’t truly be measured. In other words, either Radyology has implicitly agreed that Frank is more productive, but that it doesn’t matter (which is false, Peter was more productive), or that there’s no way to measure productivity, which it also false.

It’s true, the rest of the blog post comes so painfully close to understanding what real software productivity is, but the arguments that follow the Frank and Peter example end up just kind of muddling the point. Radyology could just as easily say ‘this isn’t productivity, that is and here’s why’ but it doesn’t. Instead he says there’s no such thing, which is a myth that we have to quash if we ever want to begin optimizing productivity.

Indeed, many of the comments allude to such.

Let’s start with a very simplified textbook approach to productivity – we’ll say a worker at a widget factory who produces more widgets per hour than another with the same level of quality is more productive. He produces more of the output (widgets) for every unit of input (hours).

Now let’s take a step back on both of those. What is the unit of output in software development? Well, that’s still a big question, on which the Peter and Frank example requires two points to be made. What’s a unit of input? This is easier, salaries*.

So productivity here could be measured by:

Magic unit of output / Salaries

Since both Frank and Peter took about one day, we’re going to say the unit of input is equal.

There’s two points to be made to figure out our magic unit of output. For one, we need to consult the marketing department, and the other, the finance department.

Ben argues that good software developers remove problems. This is very close to the truth; it’s more accurate to simply say good software developers solve problems. That means we’re on track towards our unit of output when we produce a solution to a problem, notably, a customer’s problem. It’s clunky to say solutions per dollar, which is what the unit would be in our above equation, so we’ll turn to the marketing department who can magically give reasonable estimates of dollars per solution a customer will pay. So we’re back to dollars output to dollars input – what is the dollar value of a solution a customer is willing to pay per dollar input the programmer requires to do the work?

“BUT!” you might say, “Not all solutions are equal!” Under the above assumptions, Frank and Peter were equally productive. The produced the same solution to the same problem in about a day’s worth of time. Here’s where we walk to the other part of the building where the finance people live and count their piles of ill gotten money.

The value of a thing is more than its simple market value. To be technically correct, it’s the discounted value of all future payments minus the costs. Now, the first part, discounting future payments, is easy enough that the Marketing department better have already done it for you in giving their estimate of value for a feature. But the second part, minus the costs, they couldn’t have done since they don’t have ways to estimate costs. You do.

By saying we discount the value of future payments, which means we’re trying to get one lump sum that represents all customer purchases driven by a feature. If some buy tomorrow, and others buy a year from now, we want to add those together but also represent some cost due to people buying in the far future. It is better to have a dollar today than a dollar in a year. Again, the marketing department better have already done that for you.

You might also wonder whether we’ve already taken into account costs – after all, salaries were already in the equation stated above. Certainly, direct costs of today are taken into account. But are those all the costs? If we’re discounting the value of future revenues, we also need to think of all future costs. It is here where Peter’s solution is clearly superior.

Peter’s solution starts with the value of the feature, and then increases that by taking away a future cost we already had to deal with. Namely, the maintenance cost of 100 SLOC. Frank’s solution, on the other hand, started with the value of the feature and then decreased that value by adding future costs that we previously did not have to pay for, the maintenance cost of 1000 SLOC, associated tests and documentation. Indeed, if it’s true that maintenance costs per line of code dwarf actual development costs per line of code, this swing from -100 SLOC to +1000 SLOC could have changed the cost equation substantially, possibly even by an amount justifying the much vaunted claim of 10x productivity.

So to sum up, programmer productivity is clearly stated by the following:

[(Value of solution to customer) – (Net present value of costs of solution)] / (Programmer Salary and time commitment)

Where the value of the solution to the customer is usually provided by marketing, NPV of costs is usually ignored by management, programmer salary is small enough to be ignored and time commitment is thrown out because we can just make the lazy bastards work overtime.

I kid of course, about that last part.

*To a lesser extent, time is also an input. Some problems cannot be resolved in under a certain amount of time (i.e., can’t be parallelized below a certain point), so time is as much a resources to be spent as money. But for the most part, we’re talking about the same units of inputs in both Frank and Peter’s case, about one day’s pay.


November 21, 2012 - Posted by | Uncategorized


  1. Agreed.

    I think software engineers fear being measured because they understand how simple measurements work and understand that there’s so much missing. Some high up manager looking at number bugs fixed and number of lines generated will not have an accurate understanding of each team member’s value. Effective measurement techniques would encourage developers to improve competence and habits which have greater benefit to a company’s bottom line. While I agree with the overall point that fewer lines of code are generally easier to maintain than more lines of code, I feel that this is a bit of a simplification. I personally prefer the term technical debt and could imagine a third solution which refactored the code with no net gain or loss of lines that fixed the problem, made the code easier to understand and harder to create bugs in going forward. Even in a world with such fuzzy concepts as technical debt, it is easy to see that some developers produce so much more than others (indeed many times worth).

    Comment by adamchase13 | November 26, 2012 | Reply

  2. Of course, as adamchase13 said, measurements may be perceived as too simple to embrace software productivity. And many people are wondering whether measurement’s needed at all, like on one of my favourites blogs: .
    From my experience (not only software but quite often) I may say: ask enterpreneurs if they do measurements, checking out the objective sings of their companies successes. And you’ll have an answer.

    Comment by myselfdevelopmentblog | August 14, 2016 | Reply

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: