Metrics That Matter

by Admin 9. April 2012 14:07

Recently a member of a group of which I am enrolled posted a question, “How many lines of bug free code can a seasoned developer write in a day?”  This question tends to get the hackles of most developers to stand straight up (I am no exception).  But why do we become so offended by this question?  What has made this question a general taboo in the development community?  

I took some time to think about it and my thoughts turned to my grandfather.  He was a machinist for GE for 40+ years and his job was to work a 10-40 ton press and manufacture parts for various GE products.  He was a skilled laborer and I am under no delusions I could perform his job, however, he made the same part over the duration of his day.  His performance was measured by the number of parts he crafted minus the number of defective parts he created.  In machining this is a standard metric and one that is very easy to equate to the profit vs. expenses.

Trying to fit development into the same bucket is impossible.  We are not creating the same exact piece of code each day.  Equating average lines of code to throughput is analogous to judging the quality of a book based on the number of pages.  “If Book A has 200 pages and Book B has 400 pages, then obviously Book B is twice as good.”  Not really a metric used by most publishing houses.

But we are still left with the question, “what are good metrics for determining the effectiveness of a developer?”  For my projects I usually subscribe to the agile method of software development.  There are clear metrics for determining the success of a project and the effectiveness of a developer.

  • The team determines their low and high end effort/story points (most effort points are loosely based on the Fibonacci sequence 1, 2,3,5,8, 13, 20, 40, 100 and infinity).  An example of a 1 would be a label change, where as a 20 would be the creation of a workflow service to guide users through an application.
  • User Stories (feature requests) are examined and converted into effort points (this is usually done by consensus.)    40 and greater usually become “epics” and are broken down into smaller user stories.
  • User stories are added to a “Sprint” based on the number of effort points allowed in that given sprint (velocity). Example: Sprint 1 takes 2 weeks and has a maximum velocity of 100 points 
  • User stories are then converted to tasks in a sprint meeting. 
  • Tasks are given a duration and assigned to users.

After just a few sprints patterns start to emerge.  Effort points and durations start to have a clear correlation.  Based on this, management reports can be created that clearly show star developers vs developers that may need extra help from the more seasoned developers.

This type of metric does not implement a draconian policy of you need to write x number of characters today to get your food pellet.   But rewards developers for innovation and coming up with the best solution to a problem in a time-boxed situation.



Agile | SDLC | Project Management


<<  June 2017  >>

View posts in large calendar

Page List