Productivity metrics

Many metric of productivity, code quality and similar stuff have been proposed during the years. Usually each metric has some underlying implication on how software engineering and development should or should not be done. Some are so biased that they seem created only to promote a given procedure. Well, everyone has its jobs. There are people who code, people who tell other people how to code, people who tell other people how to tell other people how to code. The things stops here because even managers understand that a fourth level of indirection is a pure waste of money.

What we know is that good developers are just more productive that bad ones. This was well known even before the whole agile movement came into existence (and even before free software was a buzzworld). In fact I found references on this in Mythical Man Month, between a praise to God and another[0]. Basically Brooks cites some studies which proved that a good developer can be 10 times more productive than a regular one. Of course I would be led to think that a 5 good developer team could achieve much more than a 50 regular developers teams because of the minor impact of communication overhead (especially considering Agile techniques, but now I'm going astray).

Of course, the number of wtf code reviewers utter gives a roughly idea on the quality of examined code... and it works independently on the number of people in the team; it does not matter how many people wrote the cr... code. If it sucks, it sucks. If it sucks it will yield a sensible and continuous stream of wtf. The actual problem is that: i) you actually need a reviewer [which you should have, but too many companies don't]; ii) you actually have to put up recording systems and tie audio files with commits, which would require huge amount of space. Simply counting the number of wtf I don't believe it works, as tone counts. There is a mild wtf and there is an astonished wtf. And there is the angy wtf. And basically you have to develop a very complex system to discern the tone and texture and mood of wtf.

Thus, here we propose the FLOC metric (Fun per Line of Code). That is to say: how much fun the developer (in a sober state) had writing the code. Unless the developer has some facial paresis which makes him look as he was smiling all the time (which is something which luckily affects only a relatively minor percentage of programmers), only a crappy jpeg needs to be associated with the commit. Software which are able to do emotion recognition from face pictures is being actively developed and its not rocket science (actually rocket, have faces, sometimes, but I find extremely bad taste when soldier paint women on bombs).

Please notice I'm half serious: if developers have fun (such as when they program in some nice freedom language) they just write better code. And work longer. Produce more. Crap! That was a secret!

----
[0] I really understand why it is considered the "Bible" of software engineering, it is because the ratio of references to God per sentence is similar to the one we find in the Bible... which I don't think it's a problem in the Bible (since it's about God), but is awkward in software engineering. To understand my feelings, consider this scenario:
[user] Can the bridge support my truck?
[engineer] God bless you.