How to Run Across a Lake
The Simplest Continuous Testing

There's No Such Thing As Software Productivity

Bill Caputo, through repeated conversations we've had, has convinced me of something very surprising. It was something that changed the way I think about the world, and how I do my job.

There is no such thing as software productivity.

As Martin Fowler observed almost a decade ago, productivity in software cannot be usefully measured. The reason why is it just doesn't exist in The Realm of Relevant Things. Put another way, productivity has no applicability as a metric in software. "How much did we create today?" is not a relevant question to ask. Even if it could be measured, productivity in software does not approximate business value in any meaningful way.

This is because software development is not an activity that necessarily produces anything. Here's a thought experiment: Let's say that you have a couple of developers working on the same project, and by accident, both of them pick up the same task on the same day. The first one, Frank, hauls off and writes a 1000 line framework that solves the problem beautifully. The code is well written, well tested, and the deployment and operation of it is well documented. The second developer, Peter, heads off to to the park for the day, where he thinks about the problem while he feeds the pigeons. Around 4:45, Peter wanders back to the office, deletes 100 lines of code, deploys the change...and the problem is fixed.

Which of these two developers was more "productive" today? The answer is: It doesn't matter. What matters the that Peter solved the problem, while simultaneously reducing long term maintenance costs for the team. Frank also solved the problem, but he increased maintenance costs by producing code, and so (all other things being equal) his solution is inferior. To call Peter more "productive" is to torture the metaphor beyond any possible point of utility.

I would argue that what good software developers do is remove problems. The opposite, in fact, of production. The creation of technological artifacts such as code, documentation, data, etc...are all necessary evils to achieve the goal of removing problems. That's why, sometimes, the most effective solution to a problem is a 5 minute conversation.

This post has been truncated. Everything after this paragraph was a rant, and not relevant to the central point. Kind of ironic, right? Thanks for reading!


Feed You can follow this conversation by subscribing to the comment feed for this post.


Brilliant. I was actually startled by your: "...deletes 100 lines of code, deploys the change...and the problem is fixed."

So so true.

Keep up the good work!


Interesting post. I think one problem with your argument is that productivity is never an abstract concept.
You start well, with the question how do you define productivity; you hint to the customer as a source to infer value, but then for some reason you fail to find metrics and arrive to the wrong conclusion that there is nothing to measure.
In reality, there is a strong measuring rod: what your customers value. If you define value from the point of view of the customer (what they are willing to pay for), it's easy to discover which processes are more productive (produce more value for your customers).


In response to Jerrylaster -

I found that article interesting too, but I don't think you can draw a direct line from the value a customer places on your software (e.g purchase price) to the productivity of the developers or the process you used to produce it. For example, if I took every shortcut and hack I could to ship a functionally equivalent product ahead of some other company that built the software in a flexible, patchable, scalable way, the customer might "value" my inferior process by buying the 1.0 but then wait forever for the 2.0 to come out because I've built an unmaintainable mess.

I think I'm making an argument for considering the longevity of the endeavor before equating customer satisfaction with development productivity...


I'll give you credit for some good thinking here. But I think the real solution here is that productivity isn't just a single measure. You can't measure productivity by measuring code output. That is like measuring people on time spent in the office.

True productivity is functional output plus maintainability per unit of time.

So you build x from scratch and deliver in a year.
You use open source for areas you can't add value to and create a well designed framework and deliver in a year.

Both deliver the customer requirements but the 2nd choice is much more productive. Less maintenance and easier future functional delivery.

Odds are the second way could have cut some of the framework and delivered requirements earlier. Whether that is good or bad depends on the project lifespan.

Good food for thought, thanks for the post.

Ben Rady

Benfield -- I strongly disagree. Functionality might be loosely related to some abstract notion of productivity and maintainability, but that doesn't mean it's valuable to anyone. Value is the essential aspect of things we care about. That's why "productivity" is such a broken metaphor. Producing functionality that nobody wants can look and feel "productive" (and programmers do this all the time). Producing functionality that a customer "wants" -- when what they need is a 5 minute explanation of what's already there -- is wasteful.


I disagree with your assessment. Nor do I feel that it's difficult to MEASURE the productivity. The issue as I see it, is that most developers DON'T measure their work.

Measuring software is simple. Unit tests measure results. You can create a new BDD test for new FEATURES, and you can create unit tests to confirm specific edge cases within the feature, and you can create performance tests to confirm the QUALITY of the results (runtime, CPU usage, memory usage, etc).

The simple issue, is that very few people bother writing tests. And few people also know HOW to write GOOD tests.

Once these tests exist, it's easy to say that both Peter and Frank successfully PRODUCED code that met the BUSINESS requirement, but that Peter's code provided a superior result by: improving performance (let's assume that deleted code leads to reduced execution time, plus Frank's solution probably added to the memory requirements), AND it was likely a MEASURABLE improvement to maintainability by improving the code coverage (since there's now LESS code to cover with tests).

Unfortunately, it seems that a lot of developers do not come from a development background (Comp Sci, Soft Eng, whatever the term)... I see more developer resumes with other backgrounds (psychology, biology, criminal science, etc)... and it seems that ONLY the people with a dev background are interested in PROVING their productivity. The rest of the people just like writing code to solve a puzzle. All fine and good for most business needs, but THAT is the source of your "no such thing as software productivity".

Isaac Gouy

>>Even if it could be measured, productivity in software does not approximate business value in any meaningful way.<<

You seem to be playing a definition word game.

As Martin Fowler observed -- "... Joe's true productivity is higher because he has delivered more business value - and I assert that any true measure of software development productivity must be based on delivered business value."

Obviously productivity does approximate business value in a very meaningful way when it is defined in terms of delivered business value.

Ben Rady

Issac G -- What I'm saying is that our use of "productivity" as a metaphor for delivering business value is flawed. "Units produced" is simply not part of the equation. We might as well try to measure 'pizzas consumed' or 'whiteboards erased'. The act of production is not necessarily related to the delivery of business value, and in some cases (as I demonstrated in my post) production results in negative net business value vs another solution to a problem.

So I think we need to stop thinking about "productivity" in software. Martin asserts "any true measure of software development productivity must be based on delivered business value". I agree, and I propose there is no such thing. We're better off dropping metaphors altogether and just talking about what programmers do: Solve problems.

Developer Dude

I agree with the article, to a degree, and to that end I think the article makes a valuable point, as do some of the comments - which add value to the discussion.

I especially like the example of the code deletion v. code creation. I have worked on many codebases where I have deleted a lot more code than I have written to fix a particular issue or even to add a feature. I always try to leave the codebase no worse than I found it, and if I can I try to improve it. If I do that by removing lines of code (as a net result) and making the code easier and simpler to understand, then I feel a lot more "productive" than if I simply add more code to the mess that is already there.

I also agree with the assessment of value as a measure of productivity, and I think there is some amount of people talking past each other here; the point of the author is exactly that of a *type* of productivity, a kind of productivity that adds value - and that is the context of "productivity", otherwise I could just sit down at my computer and work on my personal projects and say "see, I created 10 thousand lines of code today", but my boss would still fire me because what I produced was of no value to my employer and therefore I was not productive in the sense that I was employed to be.


Big +1.

Programmer productivity is a myth. Even "business value" is a cop-out. Most of the time there's no way to estimate that ahead of time, and often it's completely out of control of the developer anyway. If Marketing isn't driving anyone to your app/site/etc. then your business value is effectively $0, even if the feature would be absolutely perfect for the people that want it.

And, in the sense of a much bigger application, how can you measure the impact of a single feature? You can tell if someone is *using it*, sure. But provided it "works" and meets all the normal requirements (fast etc.) how can you tell if that increased conversions? On a team that is continuously deploying and releasing new features (or tweaks) all the time, tying that back to "business value" is impossible.

Ultimately, as has been said, any measurement of "developer productivity" is completely wrong. And, in the interest of lean development, is waste.

It's the organization's job to give developers all the support they need to do their job, then trust that they are doing it to the best of their abilities.


The comments to this entry are closed.