[hand with pencil]
Stuff For Sale
2004 Summer Tour
About
Blog
Class Stuff
Email Me
Events
Gallery
Home
In The Press
Newsletter
Services
Smalltalk
Veggie Van Gogh

Credits
© 2002,
Bytesmiths

[this is simply a banner and menu bar]

Please patronize sponsors of this page!

Bytesmiths no longer is involved in software consulting. Maintenance of this web site is currently subsidised by unrelated business activities. Please pass the word to other interested folks, so I can continue to host this page!
Your site could be listed here, for as little as $12 per month! Go to Bytesmiths Press for details.

This site has been selected by PC Webopaedia as one of the best on this topic!
This site has been awarded a Links2Go Key Resource Award in the Smalltalk category!

[ prev | top | next ]

Useful Metrics

(This is a slide show. You really won't get 
anything out of it unless you have a graphical web browser with graphics turned 
on.)
It is difficult to know what to measure before you know what is important. This often results in one of the following:
  • Measure nothing . This means you cannot claim success by any but the grossest measures, i. e. "did you improve upon normal schedule and budget," which we've already stated will be a long shot on a first Smalltalk project.
  • Measure everything . The resulting sea of data might be as useful to adversaries as it is to you! For example, "lines of code per person month" will look dismal if a lot of re-use is realized or if your team is inexperienced, and "defect count" may look abnormally high if your process stresses continuous testing.
Here are some metrics we feel are more useful than traditional ones:
  • Locality of reference : how often is "self" and "super" used? (How little are globals, class names, and class variables used? Coupling vs. cohesion analysis.)
  • Degree/use of abstraction : How deep is the hierarchy? How little are concrete class names used?
  • Code thrash : what is the average number of changes per method?
  • Interface size : how "thick" is a module's external interface? (How many methods are public, both by design and de-facto?) How "deep" is a module's interface? (How much of the implementation exposed -- does it require any Collection as an argument, or must it be an instance of MySpecificCollectionThatDoesOneThingOnly ?)
  • Function count : how many distinct functions does a module perform? ("A module having more than one design decision is 'poorer'" [Bilow 93])
  • Specification quality : What is the commentary/code ratio? Are methods/classes/modules usable without looking at (and figuring out) their code?

    [ prev | top | next ]