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".