Software metrics, when used properly, is a tool for measuring the project not individuals; it’s a tool for controlling project deliverables, assessing and communicating status, and making better decisions.

Jerry’s challenge with raising the target donations is similar to the challenges we face in estimating and delivering software projects on time. He has no way to precisely estimate how much money he can raise in the 24-hour event, yet he has a target, and he always exceeds it. Similarly on software projects, teams are asked to deliver a fixed set of requirements on a fixed date, but unlike Jerry, we are rarely successful in delivering everything on time.

When I was a child, I had a strong aversion to pineapples. Just the look of them made me ill. It didn’t matter whether it was cut or uncut; there was just something about the look that made me believe I would not like the taste. Maybe it was the color yellow, but there was something terribly unappealing about the fruit, and no matter how much my mom would entice me with declarations of how sweet it taste, I would not try it.

I felt the same way about cranberry sauce too. It was an emotional aversion; there was nothing logical about it even though I was convinced my reasons were all logical. Cranberry sauce looks slimy; slimy is disgusting; therefore, it must taste like it looks: disgusting. It’s a logical inference; though, it has little relevance to how cranberry sauce actually tastes.

As I got older, I became more open to giving foods a try (and other things, of course) that were unappealing to me. When I finally gave pineapples and cranberry sauce a try, I discovered how I’d been missing out for so long on enjoying a food that was so pleasurable to me.

Much of the software community has a similar aversion to LOC. Many of their arguments against LOC are logical, but they aren’t relevant to the science and practice of LOC as advocated by its adherents. Sure one can write a line of code with more defects than 10 lines of code, but the Law of Big Numbers says the density observed in practice will be the expected value.

Software size metrics provide benefits to managing your software projects successfully. They improve estimating, monitoring and control, and they provide objective release criteria defining when done is done. However, using size metrics on a software project requires a disciplined approach, and too often discipline is a casualty of intense pressure on software projects, but metrics, when used effectively, have tangible, powerful, and immediate benefits.

What if you could be more accurate in your software estimates?  What if you could gain more control over your project schedule? What if you could improve your product quality and know that you did …

I often wonder why software teams always seem to be committing to unrealistic schedules. You know when the sales team signed a contract with a customer to deliver functionality on a date without ever asking the engineering team whether it were possible. Never mind the roadmaps identify an entirely different set of functionality than what was committed. And guess what? The product roadmaps can’t change either; the sales team has signed contracts on that functionality too.

It happened when I participated for the first time on a SEI/CMM process improvement initiative at my employer. That’s when I realized the power of software metrics. Instead of handing us a ready made process to follow, each of the different product organizations were tasked with the objective of developing their own processes with the goal of achieving Level 2 certification. Each group formed teams around the key process areas (KPA) to develop the practices to be followed. It was without a doubt the best process improvement experience of my career changing the way I manage and view software management permanently.

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.

“Another 30 defects uncovered yesterday,” reports the QA Lead. “Ten defects were fixed,” reports the Tech. Lead. Taken alone these are alarming statistics, and if they persist long enough, the release date would certainly be in jeopardy.

Many software teams struggle through the QA phase with great anxiety as they normally work through the phase without a compass: nothing to tell them whether they are on track or not. How many defects are left? Will we be able to fix all the defects before the release date? These are a few of the questions that teams have anxiety about. It’s only until a few weeks before the planned release date that they come to grips with the realization that they are in trouble.