You Want IT When?

It’s interesting to learn what pieces the readers are most reading on this blog.  It’s typical that what the author thinks will generate the most interest is different than what the readers find most interesting.  This has certainly been my experience.  “Why Software Process Adoption Fails” has been the most read essay.  It by far has the most clicks beating the next closest essay by a 2 to 1 margin, which is “No Pain, No Gain.“  When I wrote it, I thought it captured well my experiences at adopting process in the companies where I had worked.  Frankly, I didn’t expect it to be as popular, but it’s not surprising given the feelings about process in the software community.

The one essay that I was hoping would have a large readership was “An Objective Method for Navigating Your Projects.”  Out of all the pieces published the methods described in this article can make a tremendous improvement in managing your software releases.   There are many benefits to using metrics to managing software projects.  These are the benefits that I’ve experienced:

• Metrics make release dates more predictable by improving estimating accuracy and providing greater schedule control to management and the team.

• Metrics give insight into the pace of production.

• Metrics allow you to identify delivery problems early when something can be done to correct them.

• Metrics bring objectivity and higher fidelity to status reporting.

• Metrics improve team communication.  They know where they stand better with respect to the release date.

• Metrics give the team members objective targets to work towards.

• Metrics give objective criteria for when done is done.

• Metrics provide objective measures for delivering to high quality standards.

• Metrics are the only tool for objectively measuring team improvement.

All these benefits, and others I’m sure I’m forgetting, I know to be absolutely true from experience, and yet few project teams make judicious use of metrics.  I’ve often wondered why.  Many teams collect them and never look at them.  Many times teams collect the wrong ones, and it’s a good thing they never look at them.  There has been tremendous research on the subject supporting the benefits of software metrics.  Other fields live and die by metrics.  In those fields if you didn’t rely upon rigorous metrics, it would be considered malpractice.  The pharmaceutical and financial industries are two amongst many examples.

I liken the resistance to metrics in the software community to my experience as a child with certain foods.   When I was a kid, just looking at a Pineapple made me ill.  There was no way I would try it no matter how much my mother would describe how sweet it was.  In my mind there was no way it could be good.  There was no logic that could convince me to give it a try for I knew better.  As I got older, the childlike resistance faded, and I gave it a try.  It was a wonderfully delicious fruit that I had missed out on the pleasures of for many years all because of my prejudice and my unwillingness to try.  Likewise, many in the software community come with preconceived notions about software metrics, and they are unwilling to give it a try.  The next few articles I plan to publish will present an argument and an approach for software metrics.   I ask that you keep an open mind and give it a try.  Who knows?  You may be surprised with the new tools that you can use to manage your projects more successfully.  Beware, you may only come to know of their power after you’ve tried them.