|
|
|
An Interview with Brian Sletten of Bosatsu Consulting
|
Article Topics
Introduction · AOP · Ruby Page 1 of 3
Introduction
This month's interview is with a frequent No Fluff Just Stuff speaker and a JavaOne presenter: Bosatsu Consulting's Brian Sletten.
He often speaks on software metrics, design patterns, Aspect Oriented Programming and emerging open source technologies like JmDNS and IKVM.NET.
Read on for a thoughtful commentary on the world of software metrics,
aspect oriented programming, and the increasing popularity of dynamic
languages.
Stelligent: What is your definition of code metrics?
Brian: Just as GPS devices help
you locate yourself in the world and help you plan your paths to your
destinations, code metrics are tools by which to gauge your position in
the software landscape. They can help you figure out the true state of
the source base rather than relying on perplexing intangibles like gut
reactions, hunches and "educated" guesses. By interrogating the
software itself, you can get a sense of the difficulties ahead and
perhaps some guidance on difficulties past.
Stelligent: Wow, great analogy!
What a great way to describe code metrics. It's clear that many
organizations do not use, or perhaps understand, code metrics- how do
you think the industry perceives them? Why do you think code metrics
are not widely adopted or used?
Brian: It depends on who you ask. Most developers don't think of metrics at all, and those that do probably stop at Halstead or McCabe complexity calculations. These are useful when applied appropriately, but are confusing if they are just handed to you to use.
For those that do think about metrics, the attitudes range from
mystical optimism to haggard distrust. As with most things, I think the
answer falls somewhere in the middle. If you are realistic in your
goals and diligent in your execution, I think you will find code
metrics useful in gauging levels of effort, identifying candidates for
refactoring and being able to discuss why one design might demonstrate
more desirable characteristics than another.
I think they have not been adopted as widely as they might because,
for the most part, they have been approached top-down. Managers want to
be able to measure productivity and that is the wrong way to engage
developers. If you can convince the developers to adopt the metrics as
part of their daily practices, I think they will start to realize the
benefits of that feedback loop. By identifying code that needs to be
refactored, being able to consider the state of the code when making
level of effort estimates and having the concepts by which to compare
designs, developers will feel more in control.
Metrics shouldn't be something you do after the fact. It should be
an activity that is performed as part of the development effort, as it
ties into design and code quality, maintainability, assessing test
coverage and planning for the future.
Stelligent: Yeah, I agree. I
think past abuses are hard to forget. Lines of code doesn't equal
productivity! Are there particular metrics you've found useful?
Conversely, which ones do you find are useless?
Brian: I think a lot of metrics
are useful depending on what your goals are. If you are trying to
predict failure, the only metrics that seem to correlate even remotely
are complexity, coupling and length of methods/classes. If you are
trying to make software easier to maintain there are a ton of metrics
that can be useful.
Robert Martin's metrics
are useful for managing dependencies and validating that your class
categories are appropriately decomposed on package boundaries. Cyclomatic complexity
is great for identifying code for refactoring, adjusting your LOE
guesstimates and determining how sufficient your test coverage is.
Identifying violations of the Law of Demeter
helps find unnecessary structural coupling between modules. Depth of
inheritance is a reasonable measure of the cognitive load a developer
needs to page in and the potential for conceptual entropy in the class
decomposition.
As far as metrics that are useless, I've never found number of
children (NOC) to make that much of a difference. SLOC is the most
misused metric. I understand the desire for managers to be able to
measure productivity, but SLOC basically measures typing volume. It
doesn't factor in reuse, defects or design quality.
|
|
