Let me ask you, what do you mean by productivity?
Number of Lines of Code (LoC) committed per unit time….ahhh….I know measuring LoC is a professional malpractice.
May be, number of features committed per unit time….ahhh….ok…it does not end when I commit the code, it also has to be approved by the QA. So lets say number of features approved by the QA per unit time.
Well all my features are not of same size and they don’t add same value. So really measuring number of features does not give a true picture of productivity. Also just because the QA approved the feature, it does not mean anything. There could be bugs or change requests coming from production.
How about using function points or story points or something like that?
Really? You are not kidding right?
Let me ask you something, what is the goal of software development?
Building software is not an end in itself. Its a means to:
- Enabling your users to be more productive. Making their life easier.
- Helping them to solve real business problems, faster and better
- Providing them a competitive edge
- Providing new services that could not be possible before
- Enabling users to share and find information more rapidly, conveniently
- Automating and simplifying their existing (business) process/workflow
- Innovating and creating kewl stuff to play with
- And of course making money in the process
- And so on…
Keeping this in mind, its lame to measure or think about productivity as amount of software created. I’ve never meet an user who wants more software. What users want is, to solve their problems or to enable them with the least amount of software. (no software is even better).
To be able to really help your users, you need to build the least amount of software that will not only solve the problem but will also delight them. Get them addicted to your software. IMHO, that’s the real goal of software development. One needs to use this goal to measure productivity (or anything useful for that matter).
- Checking-in code
- Having the QA approve it
- Having it deployed in production
None of these is worth measuring. For a minute, get out of your tunnel visioned coding world and think about the bigger context in which you operate. Life is much bigger. Local optimization does not really help.
I recommend you read my post about: Why should I bother to learn and practice TDD?