All of the process improvement processes are a variation on:

• Define
• Measure
• Analyze
• Act
• Control

So to improve, one must measure and one of the most requested and hotly debated metrics is programmer productivity, which is used for ratings, raises and a plethora of non-process activities.

Unfortunately, this measurement is often subject to inversion ( does not correlate well to what is being measured) and when people realize that it is being used for rating, can and will be gamed. The other unfortunate reality is the programmer productivity is actually a better measurement of the process than of the people, so it is a very useful metric if used correctly.

As always, be careful what you measure since this will often be counterproductive and drive unintended consequences as can be seen in the much quoted Dilbert cartoon -
http://dilbert.com/strips/comic/1995-11-13/

In conclusion, ensure that metrics are judiciously used and that productivity and performance are based on more than one metric

With all the buzz over noSQL, I installed one a few weeks ago, ran a few examples and smiled a lot since we are now back to hierarchical, non normalized databases.

Many years ago, when I was working in the systems division of a large banking organization, we got constant pressure to move all the databases to a 'more modern SQL database. We resisted this since, besides the migration cost, the performance impacts would have been unbearable. The same justification of high transaction rates on large databases is the reason that noSQL is being touted as the solution.

However, people seem to have forgotten what the push was to move to SQL in the first place, and are at risk of repeating past mistakes. Go and search for CODASYL and all the debates which raged over hierarchical versus relational databases and the pluses and minuses of each of the technologies and you will see that the conversations are not all that different.

Each approach has its place and the key is always using the solution that best fits the problem and not bending the problem to fit the solution.

Since each noSQL implementation I looked at has its own API, if you are going down the noSQL path, (and I do not like pre-emptive coding) at least encapsulate the data accesses so if you decide to move to a different infrastructure, that the cost of moving is limited.