A Funny Thing Happened on the Way to the Metrics

Software metrics are funny. When you want to manage by the numbers, you think counting the output of programmers can lead you to a worthwhile standard to gauge activity completion in a project. Of course, the baseline needs to be set. And then you'll need to have an estimate of that output.

Now comes the funny part. What do you count? You can't count the code words. That's like counting drops of water. They get bigger or smaller as you want depending on who is doing the coding and the measuring. You can't count the smaller modules of code. Now you've just gone from drops to small containers and again it's up to who's doing the choosing of the container.

So it's more like telling a flour manufacturer to measure a truckload of flour and then telling them to count the spoonfuls that they have. The spoon isn't standard, the level of the contents of the spoon isn't standard, and the odds that someone will make an error is high. Not to mention that it takes a dedicated staff to deliver spoonful measurements over a long period of time so that you can use control methods.

The best solution I've seen to counting code is to count the modeled application before it goes to code. It's more like measuring in standard size truck loads. The best standard is the use case defined at the same level, usually called the user goal level.

So, in my opinion, metrics for code, once having gone to code are useless. However, project metrics based on large chunks of functionality and enterprise metrics such as ROI on technology purchases, are very worthwhile depending on the control level you want.