I completely agree with a lot of what you're saying, but I feel there is a difference between what I 'produce' and what I'm paid for. As you say, I'm paid to solve business problems, so any time that I dedicate to not solving those business problems or improving the business is essentially not productive.
I'm not suggesting we count lines of code, but I'm only actually producing when the code I write makes it into a final product. If I spend 5 hours writing code, and then throw it all away, I'm not productive. When I re-write a bit of code, was I productive the first time and not the second? Was I productive both times? Does it matter what has changed between the time I wrote them both, or why I'm making the change?
Using your example of refactoring 1000 lines of code, if the 1000 lines ends up doing the same as the 100 lines, how have I added value to the business? I may not have, and therefore, that time was unproductive, or I may have added value, and therefore the time was productive.
Interestingly, it seems the definition of productive may be up for debate itself.
"If I spend 5 hours writing code, and then throw it all away, I'm not productive."
Writing throw-away prototype code can be very productive, since it's a way to learn about your domain and the problem you're trying to solve. It can certainly contribute toward making a better final product. If we're trying to solve hard problems, we can't expect to be able to come up with a perfect solution on the first try with no backtracking.
As Thomas Edison said about his numerous unsuccessful attempts to make a light bulb, "I have not failed. I've just found 10,000 ways that won't work." Each unsuccessful attempt got him a bit closer to being able to make a working light bulb.
"Using your example of refactoring 1000 lines of code, if the 1000 lines ends up doing the same as the 100 lines, how have I added value to the business?"
Speaking from first-hand experience, sometimes the code base you inherit is so bad that you can't add anything to it without breaking it. By refactoring, you've made it possible to add the new functionality to the code which your customers desperately need. You've also probably made the code more reliable, since there's less stuff in there to break in the future.
On the other hand, if you had code that worked perfectly and didn't require any new features, and you refactored it merely because it offended your sense of esthetics, then you were probably not being productive.
I think that when you dispose of code to create a better solution, say to reduce from 1000-100 lines or throw away a prototype to build a real application it's productive.
It's like throwing away the scaffolding that was supporting a building during construction but is now redundant. It's like removing the stone from the sculpture that isn't part of the figure you're trying to create.
I'm not suggesting we count lines of code, but I'm only actually producing when the code I write makes it into a final product. If I spend 5 hours writing code, and then throw it all away, I'm not productive. When I re-write a bit of code, was I productive the first time and not the second? Was I productive both times? Does it matter what has changed between the time I wrote them both, or why I'm making the change?
Using your example of refactoring 1000 lines of code, if the 1000 lines ends up doing the same as the 100 lines, how have I added value to the business? I may not have, and therefore, that time was unproductive, or I may have added value, and therefore the time was productive.
Interestingly, it seems the definition of productive may be up for debate itself.