Interruption
I will interrupt a bit this series because I have just bumped into an "old" article on software metrics, about which I would like to comment briefly: Jones, C. Software Metrics: Good, Bad and Missing, Computer, vol. 27, no. 9, pp. 98-100, Sept. 1994.
Its abstract says
"
The software industry is an embarrassment when it comes to measurement and metrics. Many software managers and practitioners, including tenured academics in software engineering and computer science, seem to know little or nothing about these topics. Many of the measurements found in the software literature are not used with enough precision to replicate the author's findings-a canon of scientific writing in other fields. Several of the most widely used software metrics have been proved unworkable, yet they continue to show up in books, encyclopedias, and refereed journals.
"
Although it was published 16 years ago, I think the problems listed on this paper are still valid, and the paragraph above manifests my opinion on the use of metrics for planning in software: they only work under certain conditions and may have worked for a given sample of projects, but may not work for my project. In my humble opinion, the current metrics don't present a sufficient level of determinism so that we can use them seriously for planning.
As I said in this series' first post, if I produce a brick here in Brazil, it will present the same size and weight in China, for instance. If I use the correct Engineering units and calculations, someone will reproduce "my experiment" of using these bricks anywhere in the Globe*. But the same doesn't occur with software requirements and thus with source code. I can send the same requirements for different people and they will implement them using different languages, paradigms, algorithms...
*(before someone say that bricks done in Brazil can present different plastic behavior in other regions of the Globe, I say that Materials Science has already developed methods to deal with this, while Software "Engineering" is still far away from doing the same for software.)
It is amazing how people use those constants found in some metrics (such as the one found in Use Case Points, which still gives 47,000 hits in Google...) without thinking that they maybe be not applicable to their specific project!
Therefore, if "So long as these invalid metrics are used carelessly, there can be no true software engineering, only a kind of amateurish craft that uses rough approximations instead of precise measurement.", I prefer to use experience and short iterations for planning.
ps. 1: the cited paper defends the use of Function Points, which I think is not applicable to Iterative & Incremental cycles.
ps. 2: I will repost a previous remark on UCP: Tell me how can you use it in an (really) Iterative & Incremental project (remember that real I&I cycles only details Use Cases when needed, so how are you going to count the number of steps for every use case and then get a "precise" effort estimation?). In spite of this, many teachers still teach UCP and I&I cycles in the same package...
"
Although it was published 16 years ago, I think the problems listed on this paper are still valid, and the paragraph above manifests my opinion on the use of metrics for planning in software: they only work under certain conditions and may have worked for a given sample of projects, but may not work for my project. In my humble opinion, the current metrics don't present a sufficient level of determinism so that we can use them seriously for planning.
As I said in this series' first post, if I produce a brick here in Brazil, it will present the same size and weight in China, for instance. If I use the correct Engineering units and calculations, someone will reproduce "my experiment" of using these bricks anywhere in the Globe*. But the same doesn't occur with software requirements and thus with source code. I can send the same requirements for different people and they will implement them using different languages, paradigms, algorithms...
*(before someone say that bricks done in Brazil can present different plastic behavior in other regions of the Globe, I say that Materials Science has already developed methods to deal with this, while Software "Engineering" is still far away from doing the same for software.)
It is amazing how people use those constants found in some metrics (such as the one found in Use Case Points, which still gives 47,000 hits in Google...) without thinking that they maybe be not applicable to their specific project!
Therefore, if "So long as these invalid metrics are used carelessly, there can be no true software engineering, only a kind of amateurish craft that uses rough approximations instead of precise measurement.", I prefer to use experience and short iterations for planning.
ps. 1: the cited paper defends the use of Function Points, which I think is not applicable to Iterative & Incremental cycles.
ps. 2: I will repost a previous remark on UCP: Tell me how can you use it in an (really) Iterative & Incremental project (remember that real I&I cycles only details Use Cases when needed, so how are you going to count the number of steps for every use case and then get a "precise" effort estimation?). In spite of this, many teachers still teach UCP and I&I cycles in the same package...
No comments:
Post a Comment