Talk:Software metric

message: I'm marking this article as Stub-class for a start, for the low quality of remaining content. But software metrics are important, so the importance is Mid (it could be High indeed). --Blaisorblade (talk) 03:46, 15 July 2008 (UTC)
replies: text: Sorry, I meant to mark as such Programming complexity. I've removed the class rating. --Blaisorblade (talk) 03:49, 15 July 2008 (UTC)
thread_title:  Assessment 

message: I got here from SLOC, where I found a subtle confusion about, or at least a failure to explicitly distinguish between, SLOC as a software metric and as an indirect means of comparing programmer skill (a worker metric?). I see that the same problem exists in this article. Perhaps because the same problem is found in the use of software metrics? It seems to me it would be worth at least drawing an explicit distinction and stating that the two goals are not the same, but are related.
Effort of producing a given program is a separate issue from of comparing different programs (or program fragments or code snippets), one or more of which possibly being imaginary, which perform comparable tasks. Given two such competing programs, there is an assumption that the skill of the programmers who produced said programs can be determined by reasoning in reverse. The argument leads to the conclusion that software metrics can themselves be used to compare the quality different programmers. However the premise that we have at hand two roughly equivalent programs to compare for "efficiency" or otherwise has not been sufficiently examined, and thus the conclusion seems suspect.
In short, software metrics are not a means to evaluate workers. Software programs can be evaluated individually using metrics, which depend on a quantitative scale and can be determined absolutely. That they can then be compared is secondary. However, worker evaluation is not relevant except when comparing two or more workers, and thus is always relative. Confusing the two ideas makes both efforts less reliable. — Preceding unsigned comment added by Kslotte (talk • contribs) 14:13, 20 October 2010 (UTC)
thread_title: SLOC confusion

message: Granted, it's been a decade+ since I took a graduate class in software metrics, but I left it with the understanding that there's two different schools of thought:
* Rigerous: Studying metrics to develop a mathematical methodology. After developing a basis, then one could draw conclusion(s), and
* Process: Metrics that analyse relationships between aspects of the code (e.g. LOC, # of defects, cyclomatic complexity, CMM stuff)
It's touched upon in the reference to process metrics. 
Is the war over? Was there a winner? — Preceding unsigned comment added by 17387349L8764 (talk • contribs) 13:04, 16 February 2021 (UTC)
replies: text: Hello, why don't you just add content and references to discussed philosophies then? Not sure when your comment was made, not cited.--𝔏92934923525 (talk) 13:04, 16 February 2021 (UTC)
thread_title:  Schools of thought 

message: Is it wise to be using the expression software metric on its own?  I believe that the word metric is not to be found in the CMM model and some researchers suggest it should be avoided.  There is ambiguity in the different definitions of the term metric.  Would the expression software measurement or at least a link to it be appropriate?
: Hi, "metrics" are, I think, much older than CMM model. In a way it goes back to measurements in general, see for example here. There are references works which go deeper, see e.g. Fenton/Bieman Close this section as done.  --𝔏92934923525 (talk) 10:20, 23 February 2021 (UTC)
thread_title: Vocabulary

message: The criticism section seems to me to be slightly off-target; it doesn't talk about the limitations of using metrics to judge software, but the related question of the limitations of using metrics to judge people and their work. It's a legitimate discussion, but I submit that it belongs in an article about management or psychology.
*I think the criticisms must also be sourced.  Who says its unethical?  How inaccurate?BillGosset 02:01, 11 June 2007 (UTC)
thread_title:  Criticism 

message: This is a software engineering topic, not a computer science topic. Why does the intro refer to computer science? Am I missing something? Adrian Sampson 23:37, 22 April 2007 (UTC)
thread_title:  Science v. engineering 

message: I find the following articles in the CrossTalk February 2001 are good and worth reading:
# Software Measurement Programs and Industry Leadership by Capers Jones of Software Productivity Research Inc.
# The Nine-Step Metrics Program by Timothy K. Perkins of Software Technology Support Center.
They provide good analysis and classification of measurements and tangible guidelines to implement measurement.  Follows the following link to read the articles:
* CrossTalk February 2001 - The Journal of Defense Software Engineering
Francis Law (talk) 04:03, 4 January 2008 (UTC)
thread_title:  Useful Articles on Software Measurement 

message: Hey all.  I'm concerned about this page being largely editorial in nature, or even original research.  There are few citations, and a lot of opinion given.  If this is common opinion in the industry, we should be able to verify it.  But even the section on balancing metrics seems highly suspicious to me, and would be widely disputed by much of the current discussion within the Lean and Agile software communities. --Christian Edward Gruber (talk) 21:04, 13 May 2008 (UTC)
replies: text: Additionally, the concepts range from software metrics for evaluating software development process control to metrics to measure personal developer productivity, but without a coherent framework for differentiating kinds of metrics, etc.  --Christian Edward Gruber (talk) 21:06, 13 May 2008 (UTC)
thread_title:  Original Research or Editorialism? 

message: I've decided that the merger can be considered approved, based on no opposition on the idea. The problem is: how to do it? Programming complexity lists various metrics unknown to me, and has a discussion about software crisis that could be placed here (maybe after replacing with a summary of software crisis), but where? --Blaisorblade (talk) 03:57, 15 July 2008 (UTC)
replies: text: I came across this today and disagree that Programming Complexity should be merged into this article. There are many different kinds of software metrics and I think it would be a mistake to merge those details into this. Cite the related articles but don't merge. --DavidBiesack (talk) 13:29, 18 December 2008 (UTC)

text: I agree with DavidBiesack. Software complexity is the subject of many, but not all software metrics. Metrics are used in order to assess or estimate complexity, monetary value or other property of a piece of software.  In essence a metric is a counting mechanism.  Complexity is a different subject.  I would like to see some detail of the things that we can count -- it's a fairly hot topic in the software development field. Gbolton (talk) 15:37, 15 May 2009 (UTC)
thread_title:  Merge from Programming Complexity 

message: I have added some extra detail to programming complexity as the merge has not yet been done.  There are some metrics listed at the bottom that I am not familiar with so I have left them alone.
As Programming/Software complexity is measured with metrics but with there being many metrics not concerned with complexity, it seems to make more sense to bring complexity into the metrics page.  —Preceding unsigned comment added by Teefertrouble (talk • contribs) 13:41, 3 September 2008 (UTC)
thread_title:  Additions to Programming Complexity 

message: A book from Tom de Marco is cited in the beginning of the article, but later on he seems to have changed his mind. Citing and article from the author :
The book’s most quoted line is its first sentence:
“You can’t control what you can’t measure.” This
line contains a real truth, but I’ve become increasingly uncomfortable with my use of it.
The article could be enhanced with those new thoughts, since it still keep the old idea that measure is more important that the author thinks that it really is.
--Vozesdoalem (talk) 17:33, 20 February 2010 (UTC)
replies: text: Hi, not sure if I get the point of this discussion, but a few things. Tom's page is here: https://en.wikipedia.org/wiki/Tom_DeMarco. For the measurement story, two interesting reads: This page and that. I call this discussion closed with the rational that measurement is an art at some point (I have scientific-engineering background) and there are pages which discuss this topic. Also see Scientific rigor. --𝔏92934923525 (talk) 10:42, 23 February 2021 (UTC)
thread_title:  Notes about a citation from Tom de Marco 

message: COCOMO the Constructive Cost Model is a methodology for estimation. In itself it is not a metric, I wonder if it should not be on the metrics list.--Colinrhammond (talk) 12:24, 27 February 2019 (UTC)
thread_title:  Cocomo 

message: Adding some new metrics, e.g. Cycle time (software) and First pass yield which are used in QA. I will elaborate later.--𝔏92934923525 (talk) 13:06, 16 February 2021 (UTC)
thread_title:  New metrics, advanced