Much has been written about software metrics from a product point of view. This author (craig@hubley.com) considers the most useful metrics to be those which measure the degree to which the software development effort reflects the priorities of its end users and funders, not necessarily in that order. Some such useful metrics include the 'churn' of a project, which is the percentage of lines of code written that are changed before (next) release, and the 'dross' of a project, which is the number of lines which are never executed or omitted before release. A more technical metric, measuring the cohesion of the source code, is the number of places in the code body that a programmer must reference and/or change while making what he, psychologically, considers to be 'one bug fix' or 'one change'. ---- '''Overview of SoftwareMetrics''' *SystemSizeMetrics **LinesOfCode **FunctionCount **FunctionPoint''''''s **NumberOfFiles *ObjectOrientedMetrics **NumberOfClasses **NumberIfChildCLasses **NumberOfReturnPoints **DepthOfInheritanceTree *ComplexityMetrics **BooleanExpressionComplexity **ClassDataAbstractionCoupling **ClassFanOutComplexity **CyclomaticComplexity **FunctionInterfaceComplexity **NPathComplexity *QualityMetrics **DesignVelocity **RunningTestedFeatures **ShodanInputMetric ---- I want both Agility and the spirit of ISO and CMMI. I want lightweight metrics that are practical for a small informal team. They should be concrete, concise, and unbiased. My small team at IBM has worked with Laurie Williams at NC State over the last year to measure our XP project. We found we improved our defect injection rate by a factor of two. But more importantly, we came up with a measurement framework for anyone who wants to replicate our study. We give you XpEvaluationFramework. Please let me know if you have feedback or suggestions. You don't have to use it, but if you're looking for ideas on what to measure it may helpful to you. I plan to continue to use it on my projects. BillKrebs ---- Going a bit afield from the first paragraph above, ... a vastly more general (and therefore vague question): What is the role of metrics in ideal software development ? The motivation for this question is simple: I want to be a better programmer. How do I get there ? Well, some of the standard wiki answers (deduced from recent traffic here and some more general desiderata) might include: * Write programs. Becoming better involves experience * Reflect upon your code. Strive to understand what worked and what didn't. * Read Tomes of Lore. These range from generic OO (Booch or Meyer) to language specific (Coplien or Beck) to project-type specific (Greenspun) to patterns (the PLOPs) to ... * Practice ExtremeProgramming * Perform UnitTest''''''s But the question remains: What is it that these things do ? If I hand you an application (both source and executable), it should take under a day to get an idea of the author's skill levels and whether the code is any good (which is not the same as whether the program is any good or whether the requirements were met or ...). Which means that, in principle, there ought to be tools that can measure this as well (based on the general principle that ''Anything I can be certain of deducing in a single day can be deduced by a computer program'' ) This, I think, is the idea behind metrics. Or, at least, one of the ideas. But, it seems to me, in all the talk here, formal metrics don't appear much. Can the benefits of RefactorMercilessly be put in terms of metrics ? Are there general heuristics for doing so ? The LawOfDemeter seems to be somewhat measurable. But what about the other practices espoused on Wiki ? As I said, a vague question. But I seem to be getting more interested in metrics these days and so I thought I'd ask. -- WilliamGrosso ---- Refactoring improves coupling and cohesion. This can be measured. The tool PatternLint [1] helps pinpoint some kinds of design warts by weighting static and dynamic object communication and comparing them. Two papers accessible from the above link have some examples. -- AamodSane ''Aamod - are you asserting that it is possible to measure coupling and (especially) cohesion mechanically? I wouldn't have thought so; have you a reference? --RonJeffries'' S.R. Chidamber and C.F. Kemerer, "A Metrics Suite for Object Oriented Design," IEEE Trans. Software Eng., vol. 20, no. 6, pp. 476-493, 1994 and L.C. Briand, J.W. Daly, and J.K. W�st, "A Unified Framework for Coupling Measurement in Object-Oriented Systems," IEEE Trans. Software Eng., vol. 25, no. 1, 1999 (don't know the exact pages) ---- ''Anything I can be certain of deducing in a single day can be deduced by a computer program'' Well, fortunately for us humans, it ain't necessarily so. We can look at a class and say whether the instance names and method names are meaningful: computers can't. We can quickly see whether the class seems to have one function or more than one: computers can't. There are some metrics that might be interesting: for example, you could look for duplicate code, or multiple messages sent to the same variable, or messages implemented but never sent. You could identify how many classes do not have UnitTest''''''s. The "only" metrics that matter to ExtremeProgramming are things like the number of UnitTest''''''s and the FunctionalTest scores (Quality), your Resource levels, the number of cards done (Scope), whether you are working overtime (Time). Many of us like to know other things, like number of classes and methods over time, average number of methods per class, average number of lines per method. Once I actually used lines per method to find some bad code to look at ... but 99 times out of 100, the code metrics we've done have been literally useless. I'm sure some folks will disagree strongly on this topic. Let's hear it, "some folks"! -- RonJeffries ---- Just a thought. If TheSourceCodeIsTheDesign and programming is designing, then I want to know whether electrical and mechanical engineers use metrics to evaluate their ability to create detailed designs in a particular amount of time, or whether this is just one of software's petty masochisms. -- MichaelFeathers ---- As far as software metrics go, I am interested in only a few measurements: *Time on task *LOC *Defects (these are basically what PSP gathers) What I need more than anything in the world is a way that I can collect this information reliably as I work without having to slow down excessively. I already face the fact that management does not feel that metrics have anything to offer us in our environment so I have to quickly prove their value. Anybody want to jump in and give me some advice? I'm very willing to share my results with the community. -- JakeWatkins ---- I was recently trying to get a handle on some new code (that is, old code that was new to me). People had pride in this old code, and I wanted a few measures that could be used to quantify some of my uneasiness. I didn't have and fancy tools, so I want for something very simple: LOC per class This is obtained very easily. in C++, I got number of classes (in a package) as grep