Not sure if you would consider it elegant, but Watts Humphrey wrote an entire book called Personal Software Process that was all about measuring your own productivity. He outlined metrics for inputs like time at your desk vs. interruptions, time spent working on various kinds of software life cycle activities, defects per amount of code. There is a technical report that gives the short version at:
If you want to look at something like the quality of a developers code, Chidamber & Kemerer proposed several metrics for object oriented code.
Metrics for object oriented code
- depth of inheritance tree,
- weighted number of methods,
- number of member functions,
- number of children, and
- coupling between objects.
Using a base of code, they tried to correlated these metrics to the defect density and maintenance effort using covariant analysis. Later studies did similar analysis on hundreds of Source Forge Java projects to determine their characteristics relative to CK Metrics and some additional metrics proposed later.
Metrics arising in context of Code Reviews
Defects can be categorized by many criteria:
- severity: (major, minor, cosmetic, investigate/unknown),
- type (logic, typo, spelling, coding standard violation, etc.),
- origin/phase containment (requirements, design, code, etc.).
There are also preparation and inspection rates (time per reviewer, time per line of code) and defect densities (per KLOC (thousand lines of code), per minute of inspector/reviewer time).
Plotting these values against control charts can show us whether we are within bounds for the process (for example, a team that inspects 200 lines of code that finds no defects in a group that averages twenty-five defects per KLOC might be malfunctioning).
Other metrics that could help include those for
Limitations of Analysis
There are tremendous limits on the value of metrics. Bugs fixed per developer can mean almost anything, and when you start to punish or reward on that measurement, I bet bugs will get more numerous and granular, and the mix of difficult to easy bugs fixed will also change as the team cherry picks in the to race to have the most.
There is also a certain distraction and potentially a loss of focus and enjoyment that can come with intrusive measurement. You can't get much more elegant (and emotionally burdened) than a lake poet like Wordsworth who said,
Sweet is the lore which Nature brings;
Our meddling intellect
Mis-shapes the beauteous forms of things:--
We murder to dissect.
While software isn't exactly Nature, give me some latitude because I thought I would never get to use anything from high school English Literature class.
Agile might be considered a reaction to centralized, big process. Sometimes that mode of work could require so much analytical effort that the ability to reach flow while creating software all but disappeared.