Software productivity management (as an end in itself) fails to account for another fundamental axiom: that software itself isn't the end-product, but itself is a tool or defines a process by which some task is accomplished.<p>Count lines of code, function points, bugfixes, commits, or any other metric, and you're capturing a <i>part</i> of the process, but you're also creating a strong incentive to game the metric (a well-known characteristic of assessment systems), and you're still missing the key point.<p>Jacob Nielsen slashed through the Gordon's knot of usability testing a couple of decades back by focusing on a single, simple metric: does a change in design help users accomplish a task faster, and/or more accurately? You now have a metric which can be used <i>independently</i> of the usability domain (it can apply to mall signage or kitchen appliances as readily as desktop software, Web pages, or a tablet app).<p>Ultimately, software does <i>something</i>. It might sell stuff (measure sales), it might provide entertainment, though in most cases that boils down to selling stuff. It might help design something, or model a problem, or create art. In many cases you can still reduce this to "sell something", in which case, if you're a business, or part of one, you've probably got a metric you can use.<p>For systems which don't result in a sales transaction directly or indirectly, "usability" probably approaches the metric you want: does a change accomplish a task faster and/or with more accuracy? Does it achieve an objectively better or preferable (double-blind tested) result?<p>The problem is that there are relatively few changes which can be tested conclusively or independently. And there are what Dennis Meadows calls "easy" and "hard" problems.<p>Easy problems offer choices in which a change is monotonic across time. Given alternatives A and B, if choice A is better than B at time t, it will be better at time t+n, for any n. You can rapidly determine which of the two alternatives you should choose.<p>Hard problems provide options which <i>aren't</i> monotonic. A may give us the best long-term results, but if it compares unfavorably initially, this isn't apparent. In a hard problem, A compares unfavorably at some time t, but is <i>better</i> than B at some time t+n, and continues to be better for all larger values of t.<p>Most new business ventures are hard problems: you're going to be worse off for some period of time before the venture takes off ... assuming it does. Similarly, the choice over whether or not to go to college (and incur both debt and foregone income), to to learn a skill, to exercise and eat healthy.<p>It's a bit of a marshmallow experiment.<p>And of course, there's a risk element which should also be factored in: in hard problems, A <i>might</i> be the better choice only <i>some</i> of the time.<p>All of which does a real number in trying to assess productivity and employee ranking.<p>Time to re-read <i>Zen and the Art of Motorcycle Maintenance</i>.