AdamNThompson wrote:
I would like it if you would elaborate though on how you go about measuring productivity, and why you feel that number 2 on my list is not measurable.
Some ways that have been tried for absolute productivity. - Bug count/lines of code - lines of code - Bug origination (integration, system, production) None of them are very good and all have problems. They are however all objective. Myself I doubt delivery time is viable as it is often dependent on other things. Additionally it isn't a matter of when but rather how accurate the schedule was in the first place. That last is a measurement that can be made and one that can improve over time but that is a process specific to project/task management and not code development. In terms of "maintainable" you woud first need to provide a definition that leads to measurable stats. For example is your code more maintainable because it takes you less time to deliver the next release? Or someone else? And do the requirements of the next release have nothing to do with the release time? What about the time between release updates - would you expect an app that was written in 2000 and is only now being updated to be comparable to another that was released in March (2011) and will have the second release in June?
AdamNThompson wrote:
I feel like I can look at code and tell if it's going to me maintainable. I look for things like meaningful abstraction, IOC, layered architecture, and so on. If someone is making database calls in a code behind file in their UI project, or is cut and pasting the same block of code throughout their work (both of which I have seen done before), I would consider that suboptimal to maintain, and therefor unproductive.
I can look at a plate of food and guess whether I am going to enjoy it a lot, a little or not at all. And whether I could cook it myself and even make it better. That however has nothing to do with whether there is anyway to measure, in concrete business terms, how 'good' the food is nor if my attempt will be 'better'.