I was watching Corey Haines’ video
And I had these thoughts:
A challenge that I see is not so much about gathering metrics. I have been using metrics since the days of PC-Metric and PC-Lint (IIRC). I would try to get my code and designs as good as possible, without being too crazy about it all.
Later, I added 60+ metrics and 60+ audits into Together, you could even trend your results to see progress over time with a given code base. Big whoop. I even had dreams of anonymously uploading audits & metrics to a website so people could collaborate on arriving at good, meaningful values for various metrics. (I routinely got asked “What is a good level for metric x?”)
Yea, so we all know, “You can’t improve what you don’t measure.”
But what are we trying to improve? Quality? Reliability? Agility to make changes? Profit?
Just how do we correlate a measurement to a desired outcome? Can we tie a set of metrics to their impact on the business goals for the software? Less complexity equals more profit and more (happy) customers?
Or do we stop short of that and tie metrics to achieving “quality” and presume that if we target a given application to meet the “right” amount of quality, the business value will naturally follow?
This is a difficult conundrum for our industry. But we do have to start somewhere.
In the world of engineering, there exist measurements that can be tied to desired performance and cost.
We need something similar should we want to mature beyond just seat-of-the-pants and gut-feel techniques.
I am sure some folks have it down to a science… and for them, it must be a nice competitive advantage that is probably hard to share publicly.
When I do code reviews (http://www.javaspecialists.eu/services/code_review.jsp) , I use metric tools extensively, but only to guide me on what to look at. The results also need to be verified to make sure that they make sense.
Such a pity that Together nowadays does not ship with the same set of metrics that we had in the old versions. Those were really useful (probably the most useful part of Together … :-))
Thanks for the thoughts, Jon.
The main point is exactly what you said, “we need to do something.” We too often stop before we start with the fear of ‘this isn’t going to be a silver bullet.’
For my metrics project, I don’t have any dreams that it is going to be the solution to all of the problems in the industry. However, coupled with other possible initiatives, I think it can help. It is going to take a long time (10 years, perhaps?) before we can start looking back to see how far we’ve come.
Another important aspect of making metrics visible and comparable is that you can’t focus on ‘what is good’ to the point of ignoring the more important ‘what isn’t.’ There have been some great thoughts lately about how people often don’t know what they don’t know and don’t know where they can find out. 🙂 I’m hoping this can help that in a small way, too.
Heinz: i use my old TCC 6 version for the same purpose. Audits & Metrics allow me to zoom in on hot spots. Of course, I can often stand 10 feet back from a model diagram (OO or ERD) and spot woes as well.
I can only use anecdotal evidence to correlate what “bad” metrics are when I match it to interviews with the developers and stakeholders.
So, Corey has the right idea… we should man-up and start somewhere.