[ladyattis]

I think the problem is that people keep using industrial/factory models of productivity to figure out if non-industrial workers are productive (have you upsold X amount of times at the drive-thru, have you done Y commits to the repo, etc). These attempts to produce meaningful enumeration of work ultimately misses the point of what the work is about. In software development, we're largely tasked with either solving a novel scenario or automating drudgery (usually the latter but the former does happen). In either case the metric that should be used is how little work your users/clients have to do to benefit from your product. If your user/clients have to do more work to make sure their use of the app is reliable then you have problems and you should track that. But you can't track it with arbitrary measurements of commits per developer or how many weeks it takes to fix the problem (it could be multiple problems). At best, you can measure how reliable your developers are at solving those problems. How fast beyond a certain point doesn't matter (usually the time frame of your biggest clients).