Attention: We are retiring the ASP.NET Community Blogs. Learn more >

Lies, damned lies and statistics

The other day whilst reading some of ^Z's entries it struck me that he uses metrics to mark many of his important observations. This is a hallmark of many of my trusted sources of information. For example Mark has been keeping a log-book of his jogging; he can now look back through the statistics that he's been keeping and use them to check his jogging patterns. I think that this is important because - as I've mentioned previously - it's often easier to plan for where you are going if you know where you're coming from.

I'd love to come up with a set of developer metrics that you could enter into a daily logbook of entries. What statistics could you keep? Here's a list which sprang immediately from my mind:

  • Lines of code written
  • Classes created
  • Classes completed
  • Incomplete "stack" of TODO's
  • Bugs found
  • Bugs fixed
  • Working singularly or in a team
  • Working on a "current" project
  • New inventions - new ideas
  • New inventions - new creations

It would be fun to overlay the "creativity" stuff with the "TO DO" lists and other "outstanding" items stuff. Hmmm, could this be practical though {scratches head and sharpens pencil}

Metrics are a wonderous thing - are they not?

3 Comments

  • Justin, thanks for your comments and, yes, I agree that statistics taken in high doses can be fatal. Just to clear up one thing though, I'm not (for the sake of this converstion at least) interested in the metrics as a management tool but, rather as a means of reflecting over a "journey". Using Mark's jogging-log as an example he is able to reflect back on such things as:



    Number of short jogs

    Moving average of distance per week

    Which directions he runs in

    Gradients

    Times



    ...and that must be fun! To be able to look at patterns and trends over a longer period helps to provide a sense of perspective.


  • Metrics are all about quantity. They don't help qualify issues most of the time. In addition, numbers can all be torn to express exactly what you want those to say (see financial reports, ...)



    Ironically, a funny thing is about the "lines of code". What kind of projections will a manager do about that? Does a manager expects a software developer to be good as much as the "lines of code" metrics is high? Bullsh*t.



  • One obvious way that purely numerical metrics could be misleading is LOCwritten vs. #Bugs Fixed/Introduced.



    If, in a short session, someone writes a couple of hundred lines of code, and has boundary issues (the old 0 or 1 based indexing), then their metrics could eaily be perceived as lower than their neighbour who also writes a couple of hundred lines of code, but introduces one or two show stopping bugs.



Comments have been disabled for this content.