> in general, the time necessary to program a piece of software of minimal size is well-known. Thanks to Kolmogorov complexity.
You have this backwards, and you didn't read the argument. Algorithmic complexity says that the complexity of a minimal program is not computable. The argument in question asserts that algorithmic complexity is a reasonable definition for the complexity of programs, more so than e.g. line counts, function points, etc.
The size of a non-minimal program is not a good definition of complexity, it's just like line counts - you can take a simple program and pad it arbitrarily to make it look complex, or at least large.
This is mostly wrong- AC is defined asymptotically. A translator from any language/machine to any other is a fixed size, not even particularly large (50k perhaps). In the limit of larger objects this 50k becomes insignificant. [this is described in AC textbooks and mentioned in the referenced paper]
I think this is a pretty reasonable response to my paper. A couple comments-
Connell: "no serious researcher in software engineering is trying to find a guaranteed method for producing estimates of time and effort that are certain to be correct. No one is even trying to find methods that produce estimates guaranteed to be correct within a known error range."
By saying this he can ignore those who claim more than subjective estimation because they are not "serious researchers". Fair enough, but you shouldn't leave with the impression that no such claims have ever been made.
" software estimating can be a science, not just an art. It really is
possible to accurately and consistently estimate costs and schedules
for a wide range of projects",
and
"In the Certainty state [of quality management], the ob-jective of software development and software quality management, producing quality software on time with a set cost everytime, is possible."
[references in the original paper]
R.e. the CMM, read the quote in the original paper carefully and judge for yourself. It's from the beginning of what I call their "manifesto", a white paper that motivates and explains the CMM. Indeed, it stops just short of saying that they claim to estimate objectively, but it sure leaves that impression if you're reading quickly.
More generally, many people in the field don't hesitate to call
what they're doing software engineering, some call their methods "scientific".
A reasonable definition of engineering is:
"the identification of objective principles for predictably solving a
body of problems"
Is software estimation engineering of this sort? No.
I think of my paper as putting a stake
in the ground at one edge of the field,
saying "not beyond here", but the rest of the field is open.
An awareness of that 'stake' will help debunk
unsustainable claims (if such continue to arise) and also help
assign value to methods that really do work, even if
the rely on human experience.
And once more, the original paper does NOT say that
software estimation is not possible or not valuable.
Claiming that it does is a straw man, or more likely,
a reflection of the fact that you didn't read it.
Slashdot Mirror
This comment was posted twice, see response below (AC deals with the choice-of-language/machine issue)
You have this backwards, and you didn't read the argument. Algorithmic complexity says that the complexity of a minimal program is not computable. The argument in question asserts that algorithmic complexity is a reasonable definition for the complexity of programs, more so than e.g. line counts, function points, etc.
The size of a non-minimal program is not a good definition of complexity, it's just like line counts - you can take a simple program and pad it arbitrarily to make it look complex, or at least large.
This is mostly wrong- AC is defined asymptotically. A translator from any language/machine to any other is a fixed size, not even particularly large (50k perhaps). In the limit of larger objects this 50k becomes insignificant. [this is described in AC textbooks and mentioned in the referenced paper]
Connell: "no serious researcher in software engineering is trying to find a guaranteed method for producing estimates of time and effort that are certain to be correct. No one is even trying to find methods that produce estimates guaranteed to be correct within a known error range."
By saying this he can ignore those who claim more than subjective estimation because they are not "serious researchers". Fair enough, but you shouldn't leave with the impression that no such claims have ever been made.
and [references in the original paper]R.e. the CMM, read the quote in the original paper carefully and judge for yourself. It's from the beginning of what I call their "manifesto", a white paper that motivates and explains the CMM. Indeed, it stops just short of saying that they claim to estimate objectively, but it sure leaves that impression if you're reading quickly.
More generally, many people in the field don't hesitate to call what they're doing software engineering, some call their methods "scientific". A reasonable definition of engineering is:
Is software estimation engineering of this sort? No.I think of my paper as putting a stake in the ground at one edge of the field, saying "not beyond here", but the rest of the field is open.
An awareness of that 'stake' will help debunk unsustainable claims (if such continue to arise) and also help assign value to methods that really do work, even if the rely on human experience.
And once more, the original paper does NOT say that software estimation is not possible or not valuable. Claiming that it does is a straw man, or more likely, a reflection of the fact that you didn't read it.