in reply to (OT) Proving Productivity?
Basically the similar opinions expressed already.
Situation one. One spent two to three hours to hammer the client or manager on the requirements (which could span two, three days), four hours on the design (to achieve most minimal design/code spec for the req), 100 hours on coding, which, the entire project, stretched out to two to three weeks (few people work on one thing only the entire time).
Situation two. A programmer started coding the same day he received his spec, be it by email, post-it note or verbal conversation.
Often enough, many managers consider the programmer in situation two more productivity. Many people don't think a programmer is working until he's typing code. They don't consider "thinking" as work.
This is a vicious cycle leading to a lot of rework. Any kind of development always involves iteration. Iteration means each step along the way you make some progress, big or small. Rework means you take one step forward and two steps back.
Other people already mentions deliverables and milestones as a meaningful yardstick to measure "productivity."
Eventually one of the meaningful productivity measures I would care is revenue per project. There's no point to crank out a lot of products and make no money. Revenue-per-project productivity cannot be achieved through productive coding alone but through very critical examination on the requirements as well (something often considered "waste of time").