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

Measuring development activities should be easy - not hard.

Yesterday's discussion on "developer metrics" seemed to be a bit of a curve-ball and I received some mixed feedback. I think that one thing which threw people was when I mentioned the deadly phrase: "Counting Lines of Code" { insert sinister sound effect }. It's a bad metric and should be removed from my original posting unless (of course) you have a tool which is sophisticated enough to provide a reliable and meaningful count of lines (i.e.: working lines, raw lines, checked-in lines etc.) -- and I don't! And nor do any of the programmers that I know, so I'm gunna chuck that measurement out (for now).

The other thing that threw people - in my opinion - was that they seemed to think that I'm proposing to use the metrics as a way to manage my sub-ordinates. I'm not. At this point I want to do it for my own benefit; for me; as fun :-)

One of the quotes which Mark left rang true for me:

...Which reminds me of the wonderful remark by William Thompson (aka Lord Kelvin): "When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind: it may be the beginning of knowledge, but you have scarcely, in your thoughts, advanced to the state of science."

 

How true. How can you hope to know what "development" is until you know what the components of developing are? I'm sure that, to get the ball rolling you could at least place items into baskets of "stuff":

  • Doing stuff
  • Not doing stuff

That wasn't too difficult; it's not terribly meaningful but at least it's a start. Now, if you're anything like me you are likely to start wondering what each of those components is comprised of, in fact, I'm sure that with a little effort I could happily break the first category down into a very simple, meaningful list...

  • Planning stuff
  • Writing stuff
  • Fixing stuff
  • Discussing stuff
  • Learning stuff

Even if you had no lower-levels than that, you would at least have a good basis for reflection in a year's time from now. Imagine being able to look back on a year and say.... "I spent 20% of my time planning stuff, 30% writing stuff, 12% fixing stuff, 20% discussing stuff and 18% learning stuff". If you knew those simple, high-level numbers it might open the door to a plethora of unanswered questions as to the composition of each of the parts.

"20% discussing stuff", you might say, "Discussing what? Architecture? Code? Languages? Coffee? When did I discuss stuff? Was it a steady line throughout the year or did it cluster into clumps of matter? Are there any links between the times when I was discussing stuff and learning stuff? What was I learning?"... etc.

My one caveat about collecting the metrics is this... keep it absolutely simple - very simple. You don't want to fall into the trap of working for your tools and, for this tool to work it must be an absolute no-brainer to enter in to and must be very accessible so that you can enter times into it at any moment.

The notion of quantifying and measuring is extremely important to me for the very reasons outlined in the quotation above, and because I've never taken the time to measure, I really don't feel that I fully understand what "being a developer" is all about.


Those are my principles. If you don't like them I have others.
- Julius Henry "Groucho" Marx, 1890 - 1977

2 Comments

  • Basically you're reinventing a stripped-down version of the Personal Software Process (PSP). The PSP recommends using a simple notebook, since the "higher-tech" solutions were never used in practice.

  • Now that you've refactored your sample I kind of understand why you might want to impose a statistical tool over your development process. As a developer, especially when working in an MS situation, it might be nice to understand the different forms of work that I accomplish and what their statistical time relationships are.



    For instance, I might find that I spend 10% of my day checking email (probably pretty good for an MS employee considering how much email is received daily), but I only want to spend say 7 or 8% and eek out another 2% of my day for purposes of learning and discovery. Maybe I find I need to cut down on my lunch (yet another place statistics are handy, eating/exercise/wellness), so I find I'm eating too much, or taking too long, or perhaps not taking long enough (rushing my food ingestion process putting me in the bathroom for an extra percentage or two ;-)



    A great tool for managing your time is actually Outlook, though I'm not sure if I ever extended it to hold the data I needed or if it took an act of god to get sub 30 minute intervals. You wind up spending a lot of time in meetings, where Outlook already stores most of your meetings. A couple of times a day, you can head into Outlook and fill in your calendar with private events that mark how you spend the rest of your time, and then aggregate this data later for statistics. Of course, using a simple calendar planner that exists simply polls from Outlook might be just as simple.

Comments have been disabled for this content.